Re: [AVT] RE: Carrying SMPTE time-codes in RTP streams, discussion email

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

Although it seems good with minimal overhead with synthesized time-codes 
they seem to have some problems. What I can understand you have the 
following problems:

1. Needs update when the time-code is changed from content side. For 
example when concatenating program and commercials.

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.

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.

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.

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.


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.


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt