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

[Frank Xia <[e-mail]>]

Hi Ali

See my inline comments.

Cheers
Frank


----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[e-mail]>
To: "Roni Even" <[e-mail]>; <[e-mail]>
Sent: Sunday, October 25, 2009 7:22 PM
Subject: Re: [AVT] Observations on MPEG2-TS preamble drafts


> Roni,
>
> Your summary is pretty accurate except a few points I point out below.
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
>> Roni Even
>> Sent: Sunday, October 25, 2009 5:51 PM
>> To: [e-mail]
>> 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.
Frank=>The RR has never meant to to receive the burst packet before.
IMHO, there is no such relationship in rapid acquistion (fast channel 
change) case.

>
>> 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.
Frank=>Sorry for not making things clearer in our draft.  Let me have 
another shot.
1)RS identifies necessary TSes
2)RS creates new RTP packets in the format of 4588.
    a) Let's say there are two RTP packets to convey preamble,
    b) and given the SN of the first unicast burst RTP is N.
    c) The OSNs of the two preamble RTP packets are  N-2, N-1 respectively.

>
> 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.
Frank=>I tried to give you a calculation,  and you can calcuate again.
The size preamble information is small.  If you talk about the failure 
probability,
you should also take into account of  unicast burst.

In a word, either efficiency or failure probablity is  not a issue just 
because
the traffic volume of preamble information is small comparing to
unicast burst.

>
> 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.
Frank=>see my above comments

>
>> 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.
Frank=>TLOV is feaible, however, RR agnostic method is probably simpler.

>
>> 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.
Frank=>Extracting preamble information is a common step between your 
solution and ours.
The server is trying to do some basic work which works with  all RR, and 
IMHO preamble
acquisition is one of these work.

>
> 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.
Frank=>You assume all RR MUST implement RAMS.  What if there is some other 
alternative?
e.g Network-based Rapid Acquisition of Multicast RTP Sessions in
http://tools.ietf.org/id/draft-xia-avt-proxy-rapid-acquisition-00.txt.

Our solution works in both scenarios.

>
>> 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
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt