RE: [AVT] Carrying SMPTE TimeCode in RTP, summary

["Link, Brian" <[e-mail]>]

Hi Dave,

There's an additional flavor of time stamp signaling for frame-based
audio, specified in SMPTE 339M. I think it would be useful to include
this format as a mechanism for sending time stamps along with audio. The
value of this format comes primarily in cases where RTP is used as a
pipe, with a client that already understands this format, similar to
those where the full 8 bytes of the SMPTE 12M time stamp are maintained.

SMPTE 339M is based on SMPTE 12M with several fields added. The most
important is a sample offset. Since video and audio frame time
boundaries do not generally coincide, the sample offset is used to
indicate which audio sample in the audio frame corresponds to the time
of the associated video frame. 

In its basic form, the SMPTE 339M payload is 12 bytes. There are also up
to 3 additional, optional 32-bit words, making the total 18 bytes. That
means the basic form fits within the size of RTP header extension. If
all the optional words are included, there isn't enough room in the
header.

Would it be reasonable to add the basic form of this format (as
org.ietf.avt.smpte339M/042006, I guess)? How about the format with the
optional words? One solution would be to change the length coding to
support more than 16 bytes, though I understand how that decreases the
cleanliness (and byte alignment) of the extension mechanism. An
alternative could be to define two extensions for SMPTE 339M, one for
the first 12 bytes, and the other for the optional 6 bytes.

Regards,
Brian

> -----Original Message-----
> From: Dave Singer [mailto:[e-mail]] 
> Sent: Thursday, March 16, 2006 3:36 PM
> To: [e-mail]
> Cc: Patrick Waddell; Miller,William C; [e-mail]
> Subject: [AVT] Carrying SMPTE TimeCode in RTP, summary
> 
> Many thanks for all the feedback received.
> 
> My proposed changes for this are:
> 
> 1) Add to the introduction:
> 
> There are applications where the transport of all 8 bytes of 
> the SMPTE 24M timecode are important (e.g. when the date of 
> the time-code must be known, or when the RTP transport is 
> used as a transparent pipe).  On the other hand, there are 
> cases (e.g. when timecodes are used with compressed audio) 
> when bandwidth is also important.  To support both use cases, 
> the mappings in RTCP always use full 64-bit timecodes (since 
> their frequency is assumed to be low, and in this way the 
> date portion of the timecode is supplied), and provision is 
> made for both compact and full forms inline, when bandwidth 
> may be an issue.
> 
> Receivers MUST support timecodes in both RTCP and RTP, and 
> both forms (short and long) of the RTP transmission.  
> Senders, of course, are free to choose.
> 
> Note that the short form allows frame numbers greater than 
> the long form (a field of 6 bits vs. a full BCD digit and a 
> 2-bit BCD digit, which gives a maximum transmitted value of 
> 29).  In some cases, the color frame flag (bit 11) is used to 
> 'extend' the tens of frames field from 2 to 3 bits;  however, 
> such practices are outside the scope of this specification.
> 
> [[Ed:  is this (a) true? and (b) helpful?  how does a 
> receiver know whether the tens field has been extended in 
> this way?  by seeing repeated frame numbers for the same 
> time-code second?]]
> 
> 
> 2) Clarify that framespersecond is one larger than the 
> maximum value of the framecounter (i.e. 24 if framecounter 
> runs 0 thru 23).
> 
> 3) fix some errors of english (oops)
> 
> 4) Change the RTCP format to always use 8-byte SMPTE timecodes.
> 
> 5) Change the names of the inline forms from 'implicit' and 
> 'explicit' to 'short' and 'long'.  Make the short form just 
> the binary 24 bits, and the long form both the BCD 64 bits 
> and the RTP offset, so it is always both complete and exact.  
> Note that if the timecode changes on a frame-by-frame basis, 
> this may force a new RTP packet per frame.
> 
> This seems better than having all four of 24-bit associated 
> with the RTP packet timestamp 24-bit with explicit RTP offset 
> 64-bit associated with the RTP packet timestamp 64-bit with 
> explicit RTP offset
> 
> However, the loss of 24-bit with explicit offset may be a 
> concern to some?  Please say so, if so.
> --
> David Singer
> Apple Computer/QuickTime
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt
> 

-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose.  If you
are not the intended recipient, delete this message.  If you are
not the intended recipient, disclosing, copying, distributing, or
taking any action based on this message is strictly prohibited.


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt