Re: [AVT] new draft on MPEG-TS preamble acquisition

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi Frank, inline.

> -----Original Message-----
> From: Frank Xia [mailto:xiayangsong at huawei.com]
> Sent: Thursday, October 22, 2009 3:03 PM
> To: Ali C. Begen (abegen); avt at ietf.org
> Subject: Re: 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

Not RR but RS.

>    2) RR generates  summary packets

Again it is RS that generates the packets.

>    3) RS  transforms the summary packets into
>       demux/decoder friendly stream in order to
>       feed demux/decoder.

This should be RR.

> 
> Our proposal skips step 2 and simlifies step 3.  That is,
> let RR directly generates demux/decoder stream.

Yes, you skip the 2nd step but at a large cost IMO.
 
> 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.

You are carrying something in RTP, so one way or another, you are defining a new payload format. As I mentioned earlier, usage of 4588 does not seem to be correct here.
 
> - 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 .

How? The raw TS packets you need will not necessarily be consecutive. If you will have to keep redundant TS packets to keep the continuity, it will be far less efficient. You can set the discontinuity flag but there are limits on it.

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

Preamble is small, correct. But the size of all TS packets making up the Preamble is not.
 
> - 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.

The above draft does not address my question. And PCR was just an example. Different TLVs are often needed for different things to speed up the acquisition.

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

For example, you might feed the TS packets with the PAT/PMT/etc to the demux but once they are gone, they are gone. In certain cases, having that info readily available and using more than once may greatly help. In our post-processing, we can do it. But, if you don't have post-processing, I suspect you cannot do it or is at least more difficult.
 
> - 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.

I am not sure what you mean here. Of course, RAMS takes care most of the stuff. Here we are addressing the specific reqs for the MPEG2TS content. If we will only provide marginal benefit, I don't see much point in doing this (we would just use RAMS). If we are here to do something, I think we should decide on the best approach.
 
> 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.

The preamble packets are sent in the same retransmission session with the burst packets. But, that does not mean that they are 4588-formatted packets. Actually they cannot be since they are not the retransmissions of other RTP packets. In a typical RTP packet, there are 7 TS packets. I cannot get a few of those TS packets and send them as retransmission packets since the resulting RTP packet is a different packet now.

Either you are misusing 4588 or sending every whole RTP packet that carries a TS packet needed for your preamble (which might be OK from 4588 viewpoint but as I said will be pretty inefficient). Or, I am totally missing how you are doing it.
 
> 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

-acbegen