Re: [AVT] Carrying SMPTE TimeCode in RTP

[Chuck Harrison <[e-mail]>]

Dave Singer wrote:

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

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.




Dave Singer wrote:
> 
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt