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

Re: [AVT] 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.

- 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.

- 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).

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.

- 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?

- 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.

- 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.

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)?

- 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? 

Also check 4588 about the use of timestamps. The way you set the timestamp is not the way 4588 mandates.

This is a short draft, but brings forward a lot of questions/issues with it.

-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