Re: [AVT] Observations on MPEG2-TS preamble drafts

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

Roni,

Your summary is pretty accurate except a few points I point out below.

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Roni Even
> Sent: Sunday, October 25, 2009 5:51 PM
> To: avt at ietf.org
> Subject: [AVT] Observations on MPEG2-TS preamble drafts
> 
> Hi,
> 
> I read both drafts and I would like to present my view as an individual trying to clarify
> what I understand from both drafts and give my view on some of the issues raised on the
> mailing list.
> 
> 
> 
> I would like to start with an observation that RAMS is not a retransmission solution as
> specified in RFC 4588  "RTP retransmission is an effective packet loss recovery technique
> for  real-time applications with relaxed delay bounds.". There is no packet loss in this

This is open to interpretation. I view RAMS as the receiver has lost everything so far (or for a long time) and subsequently lost its "synchronization (or whatever we wanna call it)" with the primary mcast stream and thus is asking the retransmission server to send whatever that is necessary to put him back on track. This is what we said in our slides since day one. 

But, this is not that relevant to the current discussion.

> case. It is using the same mechanism to convey information that will look to the RR as a
> retransmission stream using the RTP packet structure defined in section 4 of RFC 4588 and
> the SDP description from RFC 4588.  Yet the RR did not know that it was missing any RTP
> packet with specific sequence numbers since he was not expecting them in the unicast
> stream until they arrived and the OSN value is not that meaningful to it.

OSN is meaningful when it joins the mcast session. Now, it can put the packets in the right order and the only relation between the retransmission (burst) packets and the multicast source packets is the OSN field.
 
> Now when talking about the preamble / PSI or information that the RR needs which may have
> been transmitted many packets ago I see in the two drafts two directions to convey the
> information
> 
> 1.       Specified in the Begen draft is to convey the information using a new payload
> format that will include the needed information as a set of TLOV elements payload.
> 2.       Specified in Xia draft that conveys the information looking like a regular MPEG2
> TS retransmission packet but since it is generated by the RS it may get an OSN that is
> before the OSN of the first RAMS unicast stream.

In both drafts, the preamble packets are created by the server. We differ in what we put in the packets. In Frank's draft, I am still missing how one can set the OSN field. I also asked Frank to demonstrate how he generated the preamble packets.

I will give a "very" simple example here. Suppose each RTP packet is carrying 7 TS packets and the server is receiving all the RTP packets sent in the multicast session (numbers below denote the RTP seqnums). 

... RTP_(N+2)   RTP_(N+1)   RTP_(N)   RTP_(N-1) ...

Assume that the current preamble (recall that preamble data varies over time) data is a combination of the information carried in the second TS packet in RTP_(N-1) and the third TS packet in RTP_(N+1).

In our approach, we extract this information and create the necessary TLOV elements, generate a new RTP packet and send it to the RTP receiver requesting RAMS for this multicast stream.

Now, what does Frank's draft do here? I see two possible answers: 
i) Extract those two TS packets and put them in a new RTP packet and send it. If this is the case, what payload format is used? Is it 4588? If so, how is the OSN field set? If not, which format is used?
ii) Retransmit the two RTP packets (i.e., N-1 and N+1) intact. In this case, 4588 can be used similar to RAMS. But, this introduces new problems. 

First, in this example the amount of info we needed was equal to or (likely) smaller than 2 TS packets, but we transmitted two full RTP packets. This is not only inefficient but also increases the chances of loss for the preamble data. Our approach squeezes all the preamble data out of several TS packets and often generates a single RTP packet. If that packet makes it, we are done. However, if the other approach will be transmitting k RTP packets (because k different RTP packets carried partial preamble data), the failure probability will go from p to k*p. This is no good.

If (i) is used instead of (ii), due to padding and other redundant info in TS packets, it is still likely that the server will generate more RTP packets than the TLOV-based approach. So, failure chances will almost always be higher.
 
> I cannot say which one is better. My personal analysis is that in both cases the RS will
> need to cache this information and will need to create the right packet structure which is
> the TLOV in the first case and an MPEG2 TS PSI packet in the second case. The RR will need

Yes, the server needs to do some processing one way or another. Generating the TLOV elements is not a concern at the server since the server is already dealing with lots of TLV elements in RAMS transactions anyway. More importantly, the number of TLOV elements that the server needs to create is proportional to the number of MPEG2-TS streams in the system. OTOH, the number of TLV elements the server needs to create for RAMS is proportional to the number of RAMS requests, which is proportional to both the number of receivers and the number of MPEG2-TS streams in the system. If you consider that number of receivers is in the order of tens of thousands per server in a typical system whereas the number of streams is in the order of hundreds, it is quite clear that TLOV encoding of the preamble data is not a concern for the server.

> to support this payload format in the first case while I assume that in the second case it
> will look like a regular MPEG2 TS stream.
> 
>  Other points that I see is that in the first case the packet may be smaller in size and
> the extensibility can allow the RS to provide additional information that was not part of
> the original stream (I am not sure if that was the meaning here). In the second case it

Yes, in addition it also gives us the flexibility of using the preamble data in the best way for the specific decoder. Not every MPEG2-TS stream produced by even standard-compliant encoders will be RAMS-friendly. Often the preamble data will dispersed over a large time frame, across multiple packets with different repetition intervals. And even the standard-compliant decoders will be showing a different behavior based on how the preamble data is placed in the stream. So, to produce the best results, different decoders will often need the preamble data in slightly different ways. The server cannot know that and should not bother with it.

Our post processing at the client enables us to address the specific requirements of each decoder. We do the heavy lifting at the server, but also need some receiver-side processing to get the best result.

> looks like the RR will see an MPEG2 TS stream and will not need to support the TLOV
> payload format.

Frank's draft attempts to simplify the receiver-side implementation by avoiding the "post processing" stage that our draft needs. Any receiver implementing RAMS must already support TLV encoding/decoding and I don't see how avoiding the post processing of TLOV elements (which is really not different at all than TLV elements) will simplify the receiver implementation.

> I do not have any view about what is the right way and I was only trying to see if I
> understand both proposals.

Thanks for the summary. I hope I've made some points clearer. 

Cheers, acbegen. 
 
> Thanks
> Roni Even as an individual
> 
> 
> 
> 
> 
>