Subject: Re: [AVT] Re: Carrying SMPTE time-codes in RTP streams, discussion email

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Apr 2005 16:30:31 +0100

On 23 Mar 2005, at 21:55, lazzaro wrote:
> On Mar 23, 2005, at 1:32 PM, Link, Brian wrote:
>>> Let's assume the sender of the RTP stream has access to the
>>> hard disk, with its SMPTE time stamp stripe.  If the sender
>>> makes sure that the mapping it sends in the RTCP packets is
>>> such that for every AC-3 audio frame, a synthesized timestamp
>>> by the receiver will always exactly match the time code on
>>> the hard disk, then it would seem to be impossible to mask
>>> errors -- the synthesis algorithm would  always yield the
>>> timestamp that exists on the stripe.
>>>
>>> Am I missing something here?
>>
>> Technically, what you propose here works. But it goes against the
>> testing principle of "minimize the number of steps where something 
>> could
>> go wrong." There's value in knowing that the data in the original is
>> copied directly to the network rather than being translated. That
>> consideration is quite important in the market targeted by this QA
>> application.
>
> This sound reasonable to me ... for this and for other reasons we've
> discussed on AVT recently, I think we need a way to send SMPTE
> in the RTP flow, for situations where apps need to do that.
>
> Seems like "inline RTP" SMPTE options under discussion have
> included:
>
> [1] Using the RTP header extension facility, and in the process
> developing a normal way to use extensions flexibly (David Singer).
>
> [2] A new RTP profile (as I recall, Magnus was concerned about
> profile combinatorial explosion ...)
>
> [3] A wrapper payload format (Colin, as I recall ...)

If there is a need for this functionality, one of these three would 
seem to be the right approach (or possibly the use of RTCP to convey a 
mapping). At this time I'm leaning towards defining a standard header 
extension, but we should explore the other solutions to understand the 
trade-offs to be made.

> [4] Add into new payload formats that expect use in pro apps
>      (such as AC-3 -- whose proposal led the search for more
>       general-purpose solutions.  However, if there are reasons
>       to have both -- general purpose and payload-format specific --
>       these would be good to discuss too).

I don't think this is a good solution: we'll just end up with many 
different ways of conveying the same information, which is not good for 
anybody.

Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt