[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] MPEG2-TS preamble drafts

We're clearly mis-communicating. Let's defer this to the meeting this afternoon. Unfortunately I can't make it, but Ali and Jeff will be there and they understand the stuff as well or better than I do. 

Thanks, DaveO.


On Nov 10, 2009, at 12:32 PM, Peilin YANG wrote:


Thank Ingemar and David,
Increased transmission overhead(Ingemar)： I don't think it is a drawback. We got all of MPEG2-TS streamings from operators which only need two MPEG2-TS infromation - PAT and PMT, CAT is necessay if it exists. I cannot ensure that all of MPEG2-TS streaming only need these two PAT and PMT infromation, but I estimated that at least above 80% MPEG2-TS streaming only need PAT and PMT. If it only has two TSs(188*2 = 673 bytes), the overhead is si mialr to the new format. PCR is dense and its time is early than Video'PTS and Audio'PTS, for other information SPS,PPS,SEI,PTS,etc. I think at least above 95% ES and PES contain these information.
Vulnerability to packetloss: if it is only one packet, two drafts are the same.
"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 especial 
ly on the positioning and timing of ECMs."-From David
I didn't sent a ton of useless data to test like David, but I think MPEG2-TS preamble and packets of I-frame are equally important. if packets of I-frame is on problem using RFC4588, MPEG2-TS preamble is identical.
"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."-From David
I don't completely understand the meaning. According to my understanding if our draft needs to keep a lot of history in its buffer, i also think new format needs to keep this information the same history. if one of this information lost, it also need to retransmit unless it is impossible to lose. 

Peilin

******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email 
immediately and delete it!
*****************************************************************************************

----- 原邮件 -----
发件人: David R Oran <oran at cisco.com>
日期: 星期二, 十一月 10日, 2009 上午10:25
主题: Re: [AVT] MPEG2-TS preamble drafts
收件人: Ingemar Johansson S <ingemar.s.johansson at ericsson.com>
抄送: avt at ietf.org



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.

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


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt