[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] RE: Carrying SMPTE time-codes in RTP streams, discussion email
Thanks, these are useful comments. Some responses below.
At 11:16 AM +0100 2/23/05, Magnus Westerlund wrote:
1. Needs update when the time-code is changed from content side. For
example when concatenating program and commercials.
yes, this is the reason for the use of RTCP for the mappings.
2. Needs update when the time-code to RTP TS mapping changes due to
transport. Example is if one uses RTSP, which also support
requesting media using the SMPTE time code. Then every time one hits
pause and then play a new mapping needs to be established, however
here RTSP do provide an initial mapping if one uses that time scale
in the PLAY request.
Ah yes, some update of RTSP might be desirable to express the mapping
at the beginning of a play-spurt without having to wait for RTCP.
3. There is need for a mechanism that ensures that the regenerator
uses the same drop mechanism with the same start point, otherwise up
to two frames errors in the numbering can occur. If unpredictable
dropping of frames occurs, each must result in an update of the time
code.
The location of the dropped numbers is mandated by SMPTE 12M; it's
something like "frame numbers 0 and 1 are not used in every nTH
minute" and so on, so I don't think this can occur.
Some questions to help construct requirements on the solution.
A. Is it acceptable to get the update a bit late? Using RTCP can
easily result in that the time code update arrives up to a few
seconds late. However if some latency is acceptable, the RTCP
bandwidth and the usage of the AVPF profile can ensure that one
maintain a limit on the latency to send the update.
I *think* so...
B. What need exist to have the SMPTE to indicate a specific audio
sample within a audio frame or packet? This concerns the need to be
able to indicate a RTP timestamp value that corresponds to a sample
within an audio stream that isn't the first in a frame etc. Also how
does one handle SMPTE time-codes for a interlaced video where the
RTP timestamp isn't used to indicate the half-frames display time.
There is no assumption that the RTP timestamp used in the SMPTE-RTP
mapping is the timestamp of the beginning of an audio frame, i.e. it
may be a time 'in the middle' of an RTP packet.
Comments on the proposal of having something in each media packet
and the RTP mechanism available for it. This is if the requirements
raised and deemed important points result in such a solution.
In general I think the SMPTE time code updates would be nice header
extensions. However I am very hesitant to produce yet another RTP
profile. Here I wished the RTP header mechanism was more flexible
and would allow for multiple header extensions, like the DCCP
options. If one defines a RTP header field as part of a RTP profile
for this, then we would get into deep profile problems. Then we
would have RTP extension in four dimensions: SMPTE-time codes,
security, feedback, and congestion control. Thus resulting in a
total of 16 combinations. the process of defining and combining the
different profile is starting to get to big.
Thus if there is need to have something in each packet, I would
propose to consider a wrapper payload, in the line of RFC 2198 audio
redundancy. That would allow for efficient fixed size additions
followed by the normal payload, or if really required even an
variable sized payload, at the overhead cost of 7-24 bits.
It does seem way overdue to have a simple mechanism for using the X
bit in the RTP header which is extensible (e.g. that the header
extension has a type and an X bit of its own, so it's chainable...)
If particular payloads want to include in-band mappings, they can be
designed to allow that, of course.
--
David Singer
Apple Computer/QuickTime
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt