[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] new draft on MPEG-TS preamble acquisition
Hello Ali
Thank for your insightful comments.
Besides my inline response, I would also like to
point out the methodology difference between
your document and our draft.
Your way is:
1) RR identifies, extracts preamble information
2) RR generates summary packets
3) RS transforms the summary packets into
demux/decoder friendly stream in order to
feed demux/decoder.
Our proposal skips step 2 and simlifies step 3. That is,
let RR directly generates demux/decoder stream.
BR
Frank
----- Original Message -----
From: "Ali C. Begen (abegen)" <abegen at cisco.com>
To: "Frank Xia" <xiayangsong at huawei.com>; <avt at ietf.org>
Sent: Wednesday, October 21, 2009 1:25 PM
Subject: RE: new draft on MPEG-TS preamble acquisition
Frank,
I read the draft. It is good to know more people agree that this is a real
problem. However, I have several comments and questions. I'd like to
understand why you think this is a better solution than our existing draft.
Frank=>Accuratly saying, I think we have some advantages
from some perspectives.
- First of all, is this an RTP payload format draft or not? The draft seems
to be defining that, yet, title does not say so, and the draft does not have
the sections needed for defining a new payload format. See the guidelines
document.
Frank=>This draft did not define a new payload format.
This is negotiatable if RFC4588 can't be used directly.
Some further related response see below.
- Not surprisingly, there are similarities with our draft on the subject.
The motivation for your draft seems to be using the raw TS packets as
Preamble, rather than generating a "summary" packet consisting of TLV
elements. Do you need post processing on the packets you sent before feeding
them to the demux? I suspect you do since you will be sending raw TS packets
in an order that will likely upset the demux (i.e., CC discontinuity will
likely to occur).
Frank=>We don't need post processing. I am not sure what issue you are
specifically referring to. However, CC continuity can be obtained .
From my perspective, we just move your post processing from RS to RR.
Moreover, TLV encoding is way more efficient from a bandwidth perspective.
Most of the space in TS packets goes to padding because of the fixed
188-byte TS packet size anyway. So, to me TLV encoding is the way to go
here.
Frank=>Honestly, I don't bandwidth is issue. Preamble is small size in
volume
comparing to vedieo traffic. Compressing preamble does not make perceivable
difference.
- Using a TLV also identifies each preamble element explicitly. This makes
it easier for the RR to selectively use portions of the preamble for
different tasks, e.g., priming system clock with PCR value. How do you deal
with that?
Frank=>You mean how to deal with PCR or some thing else?
As for PCR issue for unicast RTP burst,
we do have a solution
http://tools.ietf.org/id/draft-yang-avt-rtp-synced-playback-00.txt.
- In our experience, we have seen with several settops that some
manipulation of the preamble is either required or strongly beneficial.
Consider repeating PATs/PMTs until the demux is initialized with them, or
delaying sending the ECM into the decoder for some time. W/o post processing
and TLV encoding, this is hard to do.
Frank=>The more specific is more understandable. Our solution works in our
experiment.
Could you give us more information?
- Section 4 says:
"Some other preamble information included in different TSes is also
identified and stored in the retransmission server."
This sounds pretty vague. Please explain.
Frank=>I meant NIT, CAT.
No details on the contents of the RTP PSI packets. Is only 1 PAT and 1 PMT
per program included? What order are they found in? Any repetition? How is
Conditional Access data included? What about constructs required by the
video codec (MPEG-2 sequence header, H.264 SPS/PPS/SEI)?
Frank=>I will elaborate them. However, this is not the point of the draft.
Our point is draft-ietf-avt-rapid-acquisition-for-rtp-03 can be directly
used for preamble acquistion with limited extension.
Any way, identifying and analyzing preamble is common processing
for your and our solution.
- Why do you use 4588 format for the Preamble packets? They are not
retransmissions of earlier unmodified RTP packets, are they? Section 4.2
says PSI RTP packets are newly generated. Thus they cannot be
retransmissions of previous packets. How do you set the OSN fields?
Frank=>We do treat Preamble packets as unicast burst. In fact,
draft-ietf-avt-rapid-acquisition-for-rtp-03 is using RETRANSMISSION server
for
rapid acquisition.
Also check 4588 about the use of timestamps. The way you set the timestamp
is not the way 4588 mandates.
Frank=>Let me think about it.
This is a short draft, but brings forward a lot of questions/issues with it.
Frank=>Thank your comments. Our solution is simple too :-)
-acbegen
-----Original Message-----
From: Frank Xia [mailto:xiayangsong at huawei.com]
Sent: Wednesday, October 21, 2009 10:59 AM
To: avt at ietf.org
Cc: Ali C. Begen (abegen)
Subject: new draft on MPEG-TS preamble acquisition
Hi folks
We submitted the draft
http://tools.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-00.txt
which is also prototyped by our company.
This draft is another solution of the same problem comparing to
http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-02.txt.
Comments are very welcome.
BR
Frank