[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Re: Carrying SMPTE time-codes in RTP streams, discussion email
On Feb 10, 2005, at 4:24 PM, Dave Singer wrote:
Here are some thoughts on carrying SMPTE time-code information in RTP.
Thanks for sending this along ...
This establishes the time-code for all RTP times greater than or equal
to the one given, until a subsequent APP packet reestablishes the
mapping.
Let's take the simplest example of non-monotonic timecode --
a TV show segment followed by 4 30-second commercials
followed by another TV show segment. Each new footage
resets the timecode to 00:00:00:00. From what I understand,
this sort of resetting is common in some video uses, but I'm not
an expert ...
Is your proposal meant to address situations like this? It would
seem possible, if you added some sending semantics to the
your RTCP APP packets (which code:
1. the RTP timestamp of the start of the run
3. the time-code of the start of the run
to cover how senders should signal upcoming transitions
(say, 15 seconds before the transition start sending the new
RTP/SMPTE start pairing) and how receivers should interpret
APP packets that describe future RTP values (keep using the
old pairing until the new RTP start time arrives in the stream).
There's probably a limit to how short footage can be,
given the 5 second RTCP minimum sending time. And of
course, this won't work well for interactive applications, where
a new run is starting because a human hits a rewind button,
and so pre-sending new run start times far in advance won't work.
The danger with sending RTCP "late" is that receivers may
associate the wrong SMPTE/RTP pair if the receiver is not aware
that a new run has begun.
It might be argued that we could set the initial mapping also in the
SDP, since RTCP packets might get lost.
I agree, avoiding SDP for initial mappings is a good idea ...
An alternative would be to make it an RTP stream in its own right;
but the data rate is so low, this seems egregious. And by packing it
inline, we can do this backwards-compatible for gateways etc. that
already handle dual-stream.
If we go this route, there is a lot to be said for sending an RTP MIDI
stream,
and the using MIDI Time Code or MIDI Machine Code tools to give
full-function
SMPTE support. No extra work to do on AVTs part ...
the duration, in that timescale, of a single frame-count in the
'frames' portion of the time-code
Some apps may want timecode to tick backwards ... MTC supports this
by reversing the sending direction of MIDI Quarter Frame sequences.
One way to do this would be to provide negative durations. However,
since direction may change for every new start of run, it may be better
to code it in RTCP ...
hours(8) -- 0 to 255
sign(1) -- 1 for negative, 0 for positive
minutes(7) -- 0 to 59
seconds(8) -- 0 to 59
frames(8) -- 0 to (frames-per-tc-second - 1)
There may be a standardized SMPTE packing into 32-bits ...
MIDI has a specialized 32-bit packing, the 8 4-bit nibbles
of an 8-command MIDI Quarter Frame sequence, but there
may be other standardized packings too ...
---
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