Re: [AVT] Re: 30/1.001 frames per sec [was: Carrying SMPTE time-codes in RTP streams, discussion email

[lazzaro <lazzaro at eecs.berkeley.edu>]

On Feb 25, 2005, at 10:47 AM, Miller, William C wrote:
> SMPTE time code was not intended to be used for timekeeping, though 
> it's common in some facilities to do so with a jam sync once a day.  
> It's a label, intended to uniquely identify every frame on a reel of 
> videotape so that editing and cuing could be automated; hence the name 
> "time and control code".  The drop-frame algorithm is accurate enough 
> for use with two-hour reels, assuming the station's sync generator is 
> operating at the correct frquency.

[...]

> It is worth mentioning that SMPTE 12M is (still) under revision; the 
> process has been long and painful but we do see light at the end of 
> the tunnel.  Much of the pain has been due to the label/timekeeping 
> dichotomy; it is nigh impossible to add accurate timekeeping 
> capability to the standard without breaking backwards compatibility.

Maybe part of the problem we need to address in AVT is
to decide just what function(s) we're adding SMPTE to
RTP to do.  Adapting your classification scheme.  I tend to
think in terms of three functions:

Labelling:  What I believe Brian Link was interested in
for his mastering application -- SMPTE was used as
a label to associate AC-3 frames with video, as a
cross-check of integrity.

Synchronization:  My own personal interest -- how does
one integrate RTP streams into an existing studio where
SMPTE and MTC and MIDI sequencer beats are the ways
different boxes in the studio think about sync?  Integrating
RTP means adding SMPTE so that these legacy boxes
can use the SMPTE timecode for sync.  Latencies may
be in the single-millisecond level (a human hitting play/stop),
timecode can roll forward and backwards (rewind), etc.

Timekeeping:  I'd guess David Singer's interest lies partially
in this direction -- if one is interested in a long-running RTP
stream (hours, days) for content distribution, one wants
SMPTE to be accurate as a timekeeper during those long
time periods.

If AVT wants to address applications that use all three
uses of SMPTE, the scheme we come up with
needs to work for all of them.  If we're only interested in
one or two of these three uses ... our job is easier.

Generally speaking, I'd feel more comfortable thinking
about this problem inside of AVT if there were actually
(more) product designers from NAB/AES/NAMM-exhibiting
companies playing an active role in AVT, with an interest in
using what we come up with.  Without that, there is a
lot of guesswork about potential applications going on ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt