[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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt