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

[Dave Singer <singer at apple.com>]

At 2:58 PM +0100 2/23/05, Magnus Westerlund wrote:
> Hi Dave,
>
> One thing that hasn't been discussed that much, is the need to 
> actually define these things to work within RTP. Which I think puts 
> two important requirements. There will be an individual binding for 
> each SSRC present in the session. Secondly, how do you handle 
> payload type switches that results in changed RTP timestamp rate?

The SDP assocation has to be per-payload-type, not per media-type, yes.

> Dave Singer wrote:
> > > 2. Needs update when the time-code to RTP TS mapping changes due 
> > > to transport. Example is if one uses RTSP, which also support 
> > > requesting media using the SMPTE time code. Then every time one 
> > > hits pause and then play a new mapping needs to be established, 
> > > however here RTSP do provide an initial mapping if one uses that 
> > > time scale in the PLAY request.
> >
> >
> > Ah yes, some update of RTSP might be desirable to express the 
> > mapping at the beginning of a play-spurt without having to wait for 
> > RTCP.
> Which is possible if one uses PLAY request with SMPTE Ranges. 
> However it might be the case that one like to use NPT and still get 
> the SMPTE codes.

Agreed.

> > > B. What need exist to have the SMPTE to indicate a specific audio 
> > > sample  within a audio frame or packet? This concerns the need to 
> > > be able to indicate a RTP timestamp value that corresponds to a 
> > > sample within an audio stream that isn't the first in a frame etc. 
> > > Also how does one handle SMPTE time-codes for a interlaced video 
> > > where the RTP timestamp isn't used to indicate the half-frames 
> > > display time.
> >
> >
> > There is no assumption that the RTP timestamp used in the SMPTE-RTP 
> > mapping is the timestamp of the beginning of an audio frame, i.e. 
> > it may be a time 'in the middle' of an RTP packet.
>
> Okay, then it shouldn't be a problem at least not for codecs that 
> uses sampling rate = timestamp rate. Otherwise there will be a small 
> error. Which unfortunately will accumulate I think.

I don't see that it accumulates;  the math is not incremental 
per-packet, but is based from the origin point.  Essentially, your 
SMPTE time-code can be as accurate as your synchronization, since 
they use the same media clock.
--
David Singer
Apple Computer/QuickTime

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