[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] MPEG2-TS preamble drafts
Hi David
Thank you for sharing you hands-on experience.
Please check my quick reply.
BR
Frank
----- Original Message -----
From: "David R Oran" <oran at cisco.com>
To: "Ingemar Johansson S" <ingemar.s.johansson at ericsson.com>
Cc: <avt at ietf.org>
Sent: Monday, November 09, 2009 8:25 PM
Subject: Re: [AVT] MPEG2-TS preamble drafts
On Nov 10, 2009, at 11:12 AM, Ingemar Johansson S wrote:
Hi
I 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 understanding
As 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 drawbacks
1) 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.
Yes, we (actually I) did when I designed this general mechanism
(although not the encoding into an RTP Payload format) about 3 years
ago.
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.
Frank=>Could you give me a simple picture about "a
ton of useless data"? Additionally, IMHO, a variety of STB
favor STB-agnostic solution :-)
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.
Frank=>Keeping a history is mandatory for both solutions because
retransmission is common processing when a preamble packet
is lost.
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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt