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

From: "Link, Brian" <[email-masked]>
Date: Wed, 23 Mar 2005 13:32:29 -0800

Hi Magnus,

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

The SMPTE time stamp is used to determined the Presentation Time Stamp
for audio and video in the MPEG Program Stream printed to a DVD. This is
required to synchronize the audio and video, accurate to the nearest
audio sample. Accuracy to the nearest compressed audio frame is not
sufficient in the case where the audio frame rate and video frame don't
have a nice integer relationship. (I don't know how MPEG PS handles
interlaced video.)

Regards,
Brian
---
Brian Link
Dolby Laboratories, 100 Potrero Ave., San Francisco, CA 94103
phone: 415-558-0324  fax: 415-863-1373
email: [email-masked]   alt email: [email-masked]

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Wednesday, February 23, 2005 2:16 AM
> To: Link, Brian; Dave Singer
> Cc: [email-masked]
> Subject: Re: [AVT] RE: Carrying SMPTE time-codes in RTP 
> streams, discussion email
> 
> 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: [email-masked]
> 
> 

-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose.  If you are not
the intended recipient, delete this message.  If you are not the intended
recipient, disclosing, copying, distributing, or taking any action based on
this message is strictly prohibited.

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