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

From: Dave Singer <[email-masked]>
Date: Mon, 5 Jun 2006 16:56:17 -0700

Hi guys

the 339M extensions seem rather specific to AES3, 
don't they?  And actually, only one of the three 
16-bit words added is strictly needed, and it 
exactly duplicates the function of the RTP offset 
in the inline version.  Except that I express it 
as "the timecode given is associated with another 
time in RTP" and 339M says "it's associated with 
another frame of audio".

So, I am not sure we need it, do we?

* * *

Words 6 and 7 are optional words that may contain 
user private data; however their presence is 
required
when the optional delay field (word 8) is present.

Word 8 is optional.  If present, it shall contain 
a delay indication denoted by bit fields D15-D0. 
The delay field
is a signed integer that indicates the offset, in 
terms of AES3 frames, of the reference point of 
the
corresponding data burst from the defined 
reference position for that data burst.  A 
positive value shall
indicate the reference point is advanced (in 
time) from the reference position, while a 
negative value shall
indicate the reference point is delayed (in time) 
from the reference position. For instance a delay 
setting of
+2037 indicates that the reference point of the 
corresponding data burst is present in the AES3 
bitstream
2037 frames ahead of the reference position for 
the burst.  An exception is the value 0x8000 
which shall be
used to indicate no delay information is provided 
even though word 8 is present.  This gives a 
range of
±32767 AES3 frames, equivalent to approximately 
±682 msec with an AES3 reference sample rate of 
48 kHz.

At 16:54  -0800 29/03/06, Link, Brian wrote:
>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:[email-masked]]
>>  Sent: Thursday, March 16, 2006 3:36 PM
>>  To: [email-masked]
>>  Cc: Patrick Waddell; Miller,William C; [email-masked]
>>  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
>>  [email-masked]
>>  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.
>

-- 
David Singer
Apple Computer/QuickTime

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

---

From: "Patrick Waddell" <[email-masked]>
Date: Mon, 5 Jun 2006 19:59:50 -0700

Dave:
 
I am not certain that 339M is useful outside of a production environment and most likely not with RTP....  The additional bits apply ONLY to the video with which they were sampled -- most likely not connected to any video sent via RTP unless circumstances are better defined.
 
If digital video and audio need to be sent together with 339M, then they need to be packaged together...
 
Pat Waddell

________________________________

	From: Dave Singer [mailto:[email-masked]] 
	Sent: Monday, June 05, 2006 4:56 PM
	To: Link, Brian; [email-masked]
	Cc: Patrick Waddell; Miller,William C; [email-masked]
	Subject: RE: [AVT] Carrying SMPTE TimeCode in RTP, summary

	Hi guys

	the 339M extensions seem rather specific to AES3, don't they?  And actually, only one of the three 16-bit words added is strictly needed, and it exactly duplicates the function of the RTP offset in the inline version.  Except that I express it as "the timecode given is associated with another time in RTP" and 339M says "it's associated with another frame of audio".

	* * *

	Words 6 and 7 are optional words that may contain user private data; however their presence is required
	when the optional delay field (word 8) is present.
	 
	Word 8 is optional.  If present, it shall contain a delay indication denoted by bit fields D15-D0.  The delay field
	is a signed integer that indicates the offset, in terms of AES3 frames, of the reference point of the
	corresponding data burst from the defined reference position for that data burst.  A positive value shall
	indicate the reference point is advanced (in time) from the reference position, while a negative value shall
	indicate the reference point is delayed (in time) from the reference position. For instance a delay setting of
	+2037 indicates that the reference point of the corresponding data burst is present in the AES3 bitstream
	2037 frames ahead of the reference position for the burst.  An exception is the value 0x8000 which shall be
	used to indicate no delay information is provided even though word 8 is present.  This gives a range of
	±32767 AES3 frames, equivalent to approximately ±682 msec with an AES3 reference sample rate of 48 kHz.

		Hi Dave,

		

		Regards,
		Brian

		

	-- 
	David Singer
	Apple Computer/QuickTime