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

[lazzaro <lazzaro at eecs.berkeley.edu>]

On Feb 11, 2005, at 3:11 PM, Link, Brian wrote:
> Part of what needs to be checked, is
> that the SMPTE time stamps that are "striped" on a hard disk with the
> audio (one SMPTE time stamp value per AC-3 audio frame) are all
> correctly lined up with the video so that the multiplex operation will
> work correctly. The mapping between RTP time stamps and SMPTE time
> stamps isn't sufficient because it requires the receiver to synthesize
> SMPTE time stamps between mapping points, which may mask errors in the
> source.

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?

> 3.  For that matter, what's the advantage of putting these mappings in
> separate RTCP packets? Instead, encapsulating them in the same packet 
> as
> the media data instead would give a greater assurance that the receiver
> is associating the right SMPTE time value with the media data.

It sounds like you're suggesting the requirements of your application
require a SMPTE timestamp on each RTP packet ... as my comment
above shows, I don't see why that would be true (yet) ... but lets 
assume it is.

In this case, the general-purpose options would be doing it as an RTP
profile (i.e. each RTP header has an extra N octets for a SMPTE 
timecode)
or as an RTP header extension.  Traditionally, I had thought extensions 
were
meant for experimental deployments, not standards-track items ... so 
lets
assume an RTP profile for the moment.

Would this sort of profile result in full functionality for your 
application?
Or did the timestamps in your AC-3 payload format (implicitly) do more
than simply associate the RTP timestamp of each packet with a SMPTE 
time stamp?

> 4.  Note that regardless of where the mapping exists, there needs to be
> a mechanism so that the receiver can determine if and when it has 
> missed
> a mapping packet (and therefore a run boundary) so it knows that any
> further synthesized values are invalid.

Phrased in this way, RTP over a network that can lose packets might not
satisfy your requirement -- what if a packet sequence is lost that 
contains two
run boundaries?  Or are you assuming you terminate the session if an RTP
sequence number break is detected?

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt