[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt