On Nov 10, 2009, at 11:12 AM, Ingemar Johansson S wrote:
Yes, we (actually I) did when I designed this general mechanism (although not the encoding into an RTP Payload format) about 3 years ago.HiI have tried to compare the two competing ID's on MPEG2-TS preamble. Not being an expert in this area I anyway try to get an understandingAs I see it draft-xia-avt-mpeg2ts-preamble-00.txt is a simple version of draft-begen-avt-rtp-mpeg2ts-preamble-03.txt as the former does not need a specification of a new preamble format (for simplicity I call the drafts XIA and BEGEN) The benefit XIA is that the endpoints (that understands RFC4588) does not need to be upgraded to understand a new preamble format, I cannot put any weight on this possible benefit.The benefit with XIA compared to BEGEN comes with some drawbacks1) Increased transmission overhead : BEGEN compresses the preamble info into one packet while XIA needs to transmit each packet that contains the preamble. This naturally means that the overhead increases. Does anybody have some figures as regards to how much this overhead increases ?. 2) Vulnerability to packetloss: XIA transmits the packets with preamble in several RFC4588 packets, which means that if one of these packets is lost the whole preamble is rendered useless. BEGEN compresses the preamble and can can possibly use this "compression gain" to transmit two identical preamble packets to cope with lossy environments.In addition, if I was to come up with a solution to the preamble problem I would first consider the XIA alternative then the more elaborate BEGEN alternative. I am curious to know if the authors of BEGEN originally considered the alterantive outlined in XIA and if so what the motivation was to go for the current proposal.
I considered just using retransmission for about 5 minutes and realized that it used an absurd amount of bandwidth and sent a ton of useless data, when the amount of data actually needed to prime the decoder ahead of the I-frame was extremely small. it also had the hazard confusing the decoder by feeding it stale data; our real world experience with a variety of STBs is that they are very sensitive to the incoming data stream and especially on the positioning and timing of ECMs.
A secondary consideration is that pure retransmission may also require that the RS keep a lot of history in its buffer than is not needed since it will never need to be sent, so instead we extract the needed information from the MPEG2TS s it arrives and package it up for transmission when needed. This turns out to be very efficient and a small extra work factor over the work needed to parse the incoming MPEG2TS to locate the random access points.
Unfortunately I cannot say do this or that but I hope that my questions will help to advance this in a direction that is satisfactory for all./Ingemar ================================= INGEMAR JOHANSSON M.Sc. Senior Research Engineer Ericsson AB Multimedia Technologies Labratoriegränd 11 971 28, Luleå, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson at ericsson.com www.ericsson.com Visit http://labs.ericsson.com ! ================================= _______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www.ietf.org/mailman/listinfo/avt