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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

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?


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.

> > 3. There is need for a mechanism that ensures that the regenerator 
> > uses the same drop mechanism with the same start point, otherwise up 
> > to two frames errors in the numbering can occur. If unpredictable 
> > dropping of frames occurs, each must result in an update of the time 
> > code.
>
>
> The location of the dropped numbers is mandated by SMPTE 12M;  it's 
> something like "frame numbers 0 and 1 are not used in every nTH 
> minute" and so on, so I don't think this can occur.

Okay, so it is based on the SMPTE timescale. So if I receive a frame 
that has RTP timestamp corresponding without compensation that show 
0:10:00.0, then if I every 10th minute needs to remove two frames, then 
I directly skip to 0:10:00.2? The every 10 minute being an example, 
rather than the correct number. Then I don't think there will be a problem.

> > Some questions to help construct requirements on the solution.
> >
> > A. Is it acceptable to get the update a bit late? Using RTCP can 
> > easily result in that the time code update arrives up to a few 
> > seconds late. However if some latency is acceptable, the RTCP 
> > bandwidth and the usage of the AVPF profile can ensure that one 
> > maintain a limit on the latency to send the update.
>
>
> I *think* so...

This is an important point, so further feedback on this is crucial.

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


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com

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