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

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

On Feb 13, 2005, at 3:45 PM, Dave Singer wrote:
> > 5.  Finally, I've specified a different representation of SMPTE time
> > code values for the AC-3 payload format than you have. There's an
> > extension defined in SMPTE 339M for applying time code values to audio
> > frames, which may not be synchronous with their associated video 
> > frames.
> > The key difference is that the 339M format adds a 'sample' field after
> > the 'frames' field. This indicates which PCM sample in the coded audio
> > frame the (video) frame number in the time stamp is associated with.
>
> That's important.  Thanks.  It needs thought.  If the RTP clock is 
> sample-accurate, then I think I'm OK, as I am associating the 
> time-code with an RTP timestamp, which may not be the timestamp of any 
> given frame.

Yes, this issue becomes harder if we end up supporting an RTP profile
that includes a SMPTE time code in the RTP header.  We'll need some
way to SMPTE stamp headers whose RTP timestamp does not coincide
with an exact SMPTE timecode value, probably using something like
the 'sample' field Brian describes.

For example, as a rule, RTP MIDI RTP timestamps generated from a MIDI
controller keyboard will not coincide with SMPTE timestamp positions ...

---
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