Subject: [AVT] Carrying SMPTE TimeCode in RTP

From: Dave Singer <[email-masked]>
Date: Wed, 1 Mar 2006 16:42:21 -0800

Answering my own email here, I'm assuming that the answer is yes to 
the 2nd question.

The extra bits in an 8-byte SMPTE time-code can be used to
a) maintain the polarity of the code (numbers of 1s and 0s)
b) indicate the relationship of the codes to color fields
c) indicate whether it's drop-frame coding
d) and then do one of
    i) carry 4 characters more
    ii) carry a date and time-zone indication (SMPTE 309M)
    iii) carry some general SMPTE 262M data (control codes, text, 
production info etc.)

I don't believe we need color and polarity handling in RTP.
We have drop-frame in the signalling.

If we want to carry something as slowly-changing as a date or as 
unchanging as a time-zone, I on't believe that embedding it here is 
right.  Certainly thought should be applied before blindly applying 
it.  If a date is needed, it's not needed inline;  at most it would 
be in RTCP, and then I would argue for a new RTCP packet type to 
carry it.

The other two possibilities are 'general meta-data' and should not be 
sub-embedded in a time-code, in RTP, but elevated and properly 
labelled at the stream level.

So, my answer is no, we do not need the full 8-byte SMPTE time-code.

On the other open question, it's a question of taste.  I prefer it 
this way but I'm not pedantic.

At 11:13  -0800 22/02/06, Dave Singer wrote:
>In this I-D, there are still a couple of open questions.  I'm 
>wondering if any on the list can indicate their preferences, or 
>whether the editor should make his best guess.
>
>Would people like more background info (e.g. the 6 flag bits and 8 
>4-bit binary groups documentation)?
>
>* * * * *
>
>
>Open question: should we normally compute framespersecond from frameduration?
>
>Open question: should we allow for a full 8-byte SMPTE time-code 
>formatted exactly as in SMPTE 12M? We are currently missing the 6 
>flag bits and the 8 4-bit binary groups.
>
>--
>David Singer
>Apple Computer/QuickTime
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

-- 
David Singer
Apple Computer/QuickTime

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Mar 2006 17:23:47 +0000

On 2 Mar 2006, at 00:42, Dave Singer wrote:
> The other two possibilities are 'general meta-data' and should not  
> be sub-embedded in a time-code, in RTP, but elevated and properly  

Seems reasonable.

Colin

---

From: Chuck Harrison <[email-masked]>
Date: Thu, 02 Mar 2006 16:32:49 -0800

> >flag bits and the 8 4-bit binary groups.

I think the best answer is to carry the full information in the
inline form (i.e. as RTP Header Extension) and leave the RTCP
form as it is.

Despite the philosophical purity of Dave's statement about handling
"general metadata" as a separate RTP stream, I believe this is not
a practical alternative for those use cases in which the user bits
of SMPTE timecode are employed. The inline form of SMPTE time
code should be a "transparent pipe": this concept is easily
understood by the end user. Anything different attracts a
reference to the modern definition of "optimize":
  Optimize(v.t.) - to take something that works and replace
   it with something else that almost works, and costs less.

In general there is no way to interpolate missing values of
user bits through the "piecewise continuous" model so I do
not see the purpose of including the full data here. The
semantics of intermittently-updated flag bits and user data
would be hard to define. It is a legitimate bandwidth-saving
measure to leave these out of the RTCP packets.

I propose that most applications which use the in-line, header-
extension form of timecode will be handling high-quality
broadband media streams in which the extra overhead will be
acceptable.

Cheers,
  Chuck

P.S.

Oh, a couple of parting shots on the purity of metadata, and
multiple RTP sessions (streams).
(1) We have already sullied ourselves, as noted in section 7
of the draft, by not handling the timecode itself as a parallel
synchronized RTP stream. That would be "egregious".
(2) RTP implementations have a well-deserved reputation of
handling inter-stream synchronization (e.g. lip-sync) sloppily.
Flags and user data that randomly pop back and forth a frame or
two relative to the media timecode would totally break many
user apps.
(3) The precedent of impure "transparent pipe" treatment already
exists in RFC3497 (SMPTE-292M). Until problem (2) is convincingly
resolved this is probably the only approach likely to get traction
in the professional broadcast world.

-C.

---

From: Dave Singer <[email-masked]>
Date: Thu, 2 Mar 2006 18:04:49 -0800

Thanks, Chuck

I'll take all this into consideration;  it's good to get professional review!

I'm a little puzzled;  in the 'piecewise continuous' mode (using 
RTCP) it seems that it's perfectly reasonable to supply the date and 
time-zone, since even day roll-overs can be calculated perfectly 
well, no?  I agree, other meta-data doesn't work then.  But we don't 
need to save nearly as much bandwidth for something that is put into 
some infrequently occurring RTCP packets.

I think there is legitimate concern with the use of inline SMPTE 
time-codes with 9say) compressed audio, where the move from 3-8 bytes 
would be noticeable.

I'll think about it.  I don't want to proliferate modes and formats 
too much, but I hear what you are saying.

-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 03 Mar 2006 10:42:16 +0100

Chuck,

What does the user bits contain? Are user bits from multiple consecutive 
packets all going to be expected to be received? The reason I ask is if 
people are used to putting things requiring high reliability into the 
user bit that will be very problematic in RTP.

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: [email-masked]

---

From: Dave Singer <[email-masked]>
Date: Thu, 16 Mar 2006 15:36:08 -0800

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