Subject: [AVT] Re: avt Digest, Vol 9, Issue 16

From: lazzaro <[email-masked]>
Date: Sat, 15 Jan 2005 10:56:23 -0800

> From: Colin Perkins <[email-masked]>
> Date: January 15, 2005 6:57:21 AM PST
>
>  - Including a SMPTE time code in each packet is unusual, and redundant
>    with the RTP timestamp (which is mapped to an NTP-format timestamp 
> via
>    RTCP SR packets) in many cases. Is it possible to use the RTP 
> timestamp
>    instead, possibly with a signalled mapping from SMPTE time code to 
> an
>    NTP format timestamp in the SDP during session setup?

On the other hand, if the AC-3 payload keeps the SMPTE time code
in RTP, this would be a good opportunity to define the temporal 
semantics
of SMPTE time code coded inline in any RTP flow -- for example, is the 
time
code constrained to be monotonically increasing once the RTP stream 
begins?

RTP MIDI has the capability of coding a SMPTE time code stream in the 
MIDI
flow via MTC commands, so I could take these semantics and add them to
RTP MIDI Appendix C.3.3.

In some applications, the time lag introduced at the start of a
stream by syncing streams via NTP RTCP packets is not acceptable --
think of a "tape deck" application in a studio situation, where an
operator is hitting "stop, "rewind", "play", and is expecting a video 
and
an audio and a MIDI stream to all start out in sync immediately after
hitting play, not N*5 seconds afterwards -- even locked analog tape 
transports
sync more quickly than NTP RTCP.  Inline SMPTE time code in RTP streams
makes this problem easier to solve, if SMPTE time code semantics are
standardized across payload formats.

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 16 Jan 2005 01:02:31 +0000

On 15 Jan 2005, at 18:56, lazzaro wrote:
> transports sync more quickly than NTP RTCP.  Inline SMPTE time code in 
> RTP streams makes this problem easier to solve, if SMPTE time code 
> semantics are standardized across payload formats.

You could signal the mapping between SMPTE time code and RTP timestamp, 
for at least some applications. That could solve the start-up delay 
problem for many applications (I think RTSP does something similar?).

Colin

---

From: lazzaro <[email-masked]>
Date: Sat, 15 Jan 2005 17:42:00 -0800

On Jan 15, 2005, at 5:02 PM, Colin Perkins wrote:
> You could signal the mapping between SMPTE time code and RTP 
> timestamp, for at least some applications. That could solve the 
> start-up delay problem for many applications (I think RTSP does 
> something similar?).

Yes, I agree ... for applications that really are the
equivalent of a SMPTE stripe on a single tape, where
the application plays the tape once front to back,
and when a one-time delay for RTCP NTP sync at
the start of the RTP stream is OK, then it is OK to
signal SMPTE to RTP timestamp mappings in
the session description.  Rounding errors over long
periods of time is the only problem I could imagine,
but I'm guessing that wouldn't be a problem.

But, there are other apps that really want to have
discontinuous time code jumps backwards in time.
Given that RTP would not be happy supporting
discontinuous jumps of the RTP timestamp
backward in time (I would think ...), the two
options would seem to be using SIP to signal
new time code mappings, or adding a SMPTE
time code stripe in-line in the RTP stream,
either via payload formats that support it, or
via a new profile.

---
John Lazzaro

---

From: Colin Perkins <[email-masked]>
Date: Sun, 16 Jan 2005 10:42:44 +0000

> but I'm guessing that wouldn't be a problem.

I don't think rounding would be a problem. And you can avoid the 
start-up delay entirely, by signalling the corresponding RTP, NTP and 
SMPTE times.

> either via payload formats that support it, or

Yes, exactly. Now, if you need signalling anyway - to control when 
there are jumps in the media, for example the tape controls - I'd argue 
that putting the SMPTE time code into the signalling, out of band, 
would be appropriate.

Colin

---

From: Dave Singer <[email-masked]>
Date: Mon, 17 Jan 2005 09:58:05 +0800

At 1:02 AM +0000 1/16/05, Colin Perkins wrote:
>>>    with the RTP timestamp (which is mapped to an NTP-format timestamp via
>>>    RTCP SR packets) in many cases. Is it possible to use the RTP timestamp
>>>    instead, possibly with a signalled mapping from SMPTE time code to an
>>in RTP, this would be a good opportunity to define the temporal semantics
>>of SMPTE time code coded inline in any RTP flow -- for example, is the time
>>code constrained to be monotonically increasing once the RTP stream begins?
>>
>>RTP MIDI has the capability of coding a SMPTE time code stream in the MIDI
>>operator is hitting "stop, "rewind", "play", and is expecting a video and
>>transports sync more quickly than NTP RTCP.  Inline SMPTE time code 
>>in RTP streams makes this problem easier to solve, if SMPTE time 
>>code semantics are standardized across payload formats.
>

The amount of data one needs to compute a SMPTE time-code given a 
starting value, an interval, and a definition of the timestamp 
structure (e.g. fps, drop-frame and so on) is quite small.  Unless 
there are discontinuities in the timecodes (as might be caused by 
editing), this means that SDP info for the initial conditions plus 
the RTP timestamp is enough.

I have been considering defining this for ISO family (e.g. MP4) 
files.  Since there is nothing media-specific about timecodes, 
perhaps we should look at a general definition "Associating SMPTE 
time-codes with RTP streams"?
-- 
David Singer
Apple Computer/QuickTime

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Jan 2005 10:15:26 +0000

On 17 Jan 2005, at 01:58, Dave Singer wrote:
...
> editing), this means that SDP info for the initial conditions plus the 
> RTP timestamp is enough.
>
> I have been considering defining this for ISO family (e.g. MP4) files. 
>  Since there is nothing media-specific about timecodes, perhaps we 
> should look at a general definition "Associating SMPTE time-codes with 
> RTP streams"?

Sounds like a good idea. Do check what RTSP does first - I think 
there's something similar in there, which we should align with as much 
as possible.

Colin