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

From: "Miller, William C" <[email-masked]>
Date: Fri, 25 Feb 2005 11:49:02 -0800

John,

The SMPTE TV Systems Technology Committee, which has custody of SMPTE
timecode and associated standards, is meeting next week in Pasadena.  If
you don't mind, I'll pass this along so the members can mull it over in
advance of the meeting.  We might collectively or individually be able
to help.

Best regards,
Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
lazzaro
Sent: Friday, February 25, 2005 2:27 PM
To: Miller, William C
Cc: [email-masked]; Link, Brian; Dave Singer;
[email-masked]; Chuck Harrison; Colin Perkins; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

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

---

From: Dave Singer <[email-masked]>
Date: Sun, 27 Feb 2005 19:13:53 +0000

>advance of the meeting.  We might collectively or individually be able

Bill, that would be great.

John, actually I was trying to be almost "purpose neutral".  I don't 
think that SMPTE time-code should be used for time-keeping;  clocks 
are for that.  Yes, they can and should be used to "initiate" 
synchornization (at time code XXXXX punch-over to an advert) and 
sometimes even for more detail than that ("show this caption at 
timecode XXXX");  but real moment-by-moment sync is covered by 
RTP/RTCP.  Labelling is the other major use, of course;  displaying 
the time-code so external systems and people can know "where we are" 
in say a studio environment.

I'm not sure if I said it before, but I don't see a problem with 
specific payload formats having in-band statements about SMPTE 
associations;  that allows in-time announcement.  But I did want a 
"retrofittable" mechanism.

By the way, it's been pointed out to me that the draft should warn 
that I allow more bits for frame number than a binary SMPTE 12M 
label, and so direct conversion may be difficult.  And apparently the 
highest bit of the 12M label is in an odd place...

-- 
David Singer
Apple Computer/QuickTime