-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
lazzaro
Sent: Friday, February 25, 2005 2:27 PM
To: Miller, William C
Cc: Patrick.Waddell at harmonicinc.com; Link, Brian; Dave Singer;
avt at ietf.org; Chuck Harrison; Colin Perkins; lazzaro at cs.berkeley.edu
Subject: Re: [AVT] Re: 30/1.001 frames per sec [was: Carrying SMPTE
time-codesin RTP streams, discussion email
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
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt