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

From: "Link, Brian" <[email-masked]>
Date: Wed, 19 Jan 2005 15:31:12 -0800

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Jan 2005 06:56:10 -0800

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