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

[Eric Friedrich <efriedri at cisco.com>]

Frank-
  I appreciate the simplicity in your design to avoid post-processing  
of the preamble. Unfortunately, different RR implementations require  
different preamble structures. This is one reason Ali & I have  
concisely specified the contents of the TLOVs- to show what may differ  
from one RR to another. I would like to see a similar specification as  
to preamble contents in your proposal as well.

That said, I don't believe your proposal restricts you from  
customizing a preamble to a certain type of RR, it just requires some  
additional work. In our draft, the RR-specific code runs as part of  
the TLOV post-processing. Since the main advantage behind your draft  
is no post-processing, the RS would have to customize the preamble to  
each specific RR. Customizing the preamble on the RS introduces the  
need for the RS to know exactly what the RR expects in the preamble.  
This is not impossible, but does introduce more complexity into your  
proposal.

I don't believe that preamble acquisition can or should be agnostic to  
RR. The wide range of RR's (both legacy and future) requires that any  
solution be flexible enough to serve the differing needs of each.

Thanks,
Eric


On Oct 25, 2009, at 9:47 PM, Frank Xia wrote:

> Hi Roni
>
> Thank for your review, and your summary is accurate.
>
> We do recognize Avi's draft flexibility, at the same time,
> I believe our draft also has some advantages which are
> to try to avoid post-processing and to make preamble
> acquistion be agnostic to RR.
>
> BR
> Frank
> ----- Original Message -----
> From: Roni Even
> To: avt at ietf.org
> Sent: Sunday, October 25, 2009 4:51 PM
> 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 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.
>
> 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.
> Frank=>
>
> 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  
> 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  
> looks like the RR will see an MPEG2 TS stream and will not need to  
> support the TLOV payload format.
>
>
> 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
> Roni Even as an individual
>
>
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt