Subject: RE: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-01.txt

From: "Link, Brian" <[email-masked]>
Date: Tue, 25 Jan 2005 21:10:55 -0800

Hi Colin,

I'd like to argue for leaving the SMPTE time stamps in the AC-3 payload.

-The data is optional, so inclusion of the capability comes at no cost
for most uses.

-As I've done more investigation into SMPTE time code and time stamps,
I've realized that the time stamps specified in SMPTE 339M (and proposed
in this payload format) were specifically designed for AC-3 to address
the need to synchronize audio frames with video frames which run at
unrelated frame rates. It may be possible to generalize the use of this
representation to include other frame-based audio formats, but that has
not been done or needed before. It is needed for AC-3 for the
application of DVD mastering.

-I support finding a general solution for pro applications, but in the
meantime, I think there would be value in enabling this time format in
the AC-3 payload since it has already been successfully used in
products.

Would this be acceptable?

Regards (from cold Helsinki with poor network access),
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: Colin Perkins [mailto:[email-masked]] 
Sent: Thursday, January 20, 2005 6:56 AM
To: Link, Brian
Cc: [email-masked]
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-01.txt

Brian,

This use of SMPTE time codes would seem more general than for the AC3
format. If this feature is going to be useful, would it make sense to
take it out of the AC3 format, and define a general mechanism that could
be used by any RTP payload format?

Colin

On 19 Jan 2005, at 15:31, Link, Brian wrote:
> Hi Colin,
>
> Thanks for these comments and the editorial ones, too. I'll 
> incorporate the 'ptime' and 'SDP offer/answer' suggestions you have
made.
>
> I'd like to offer some motivation for including SMPTE time code. The 
> SMPTE time code feature is not needed by DLNA for their consumer 
> application of A/V streaming over a home network. However, while I was

> updating the I-D, I learned that AC-3 over RTP is also used in a 
> professional application and I'd like the payload format to 
> accommodate that, too.
>
> The particular professional application is quality control for the 
> mastering of DVDs. The audio and video are stored on separate storage 
> media, each "striped" with SMPTE time code so that in the final 
> mastering step they can be correctly multiplexed together into an MPEG

> stream. Prior to the multiplexing step, there is a quality control 
> step where the audio and video are auditioned together to make sure 
> the multiplex will be performed correctly. The purpose of the audition

> is to check the combination of the audio and video data together with 
> the time code as stored on disk. If, instead, the time code is 
> discarded by the server and regenerated at the client from the RTP 
> timestamp, the value of this test is negated. Any errors in the SMPTE 
> time on the storage medium are replaced by the regenerated time code.
>
> It's also interesting to note that the SMPTE time code is not used to 
> synchronize two RTP streams. In this case the audio, in an RTP stream,

> is synchronized with an external video device through a hardware 
> interface. RTP is being used as a "drop in" replacement for an 
> existing audio transport in a heterogeneous facility. The video stream

> is not
> (necessarily) carried over RTP. Also, the SMPTE time code for the 
> audio is not generated as the RTP stream is created, instead it was 
> created earlier and in an external part of the overall system.
>
> For most end-consumer-type applications, SMPTE time code is redundant,

> so it is optional in the payload header. For professional 
> applications, it is not necessarily redundant (and that market often 
> demands redundancy, anyway) and is already used by products in the 
> field, so I feel SMPTE time code is needed, as an option.
>
> 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: Colin Perkins [mailto:[email-masked]]
> Sent: Saturday, January 15, 2005 6:57 AM
> To: Link, Brian
> Cc: [email-masked]
> Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-ac3-01.txt
>
> Brian,
>
> On 3 Jan 2005, at 18:39, Link, Brian wrote:
>> As the quoted announcement states, I have revived the RTP payload 
>> format I-D for AC-3. I have made a number of changes to take into 
>> account comments that had previously been offered, to simplify the 
>> draft, and to add some time code functionality that is used in some 
>> products.
>>
>> An industry consortium called the Digital Living Network Alliance
>> (DLNA)
>> plans to stream AC-3 over RTP in some of its home networking 
>> applications. In order for DLNA to reference the payload format in 
>> this document (instead of publishing their own), it will need to be 
>> published in a relatively short time.  I will very much appreciate it

>> if interested people could review and comment on this I-D to move it 
>> along quickly.
>
> Mostly this looks good, although I have a couple of technical
concerns:
>
>   - 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?
>
>   - The second is that the definition of "ptime" is unusual. I think
it
>     would be better as:
>
> 	ptime: The duration of time in milliseconds represented by each
> AC-3
> 	frame. This corresponds to the duration of each RTP packet in
cases
> 	where fragmentation is not used.
>
>     without trying to define what it means for fragments.
>
>   - Finally, the draft should define how SDP is used in offer/answer 
> mode to
>     negotiate parameters. It should also describe how the MIME 
> parameters are
>     copied into the SDP (section 5.1 of RFC 3557 is a good example).
>
> I've also sent a few minor editorial comments privately.
>
> Colin
>
>
> -----------------------------------------
> 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
>

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