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

["Link, Brian" <BDL at dolby.com>]

Colin,

After reading about the offer/answer mode of SDP, I think I've come to
the conclusion that there are no special considerations necessary for
AC-3. There are no parameter negotiations needed for an AC-3 decoder
since AC-3 was designed so that any AC-3 decoder will play any AC-3
stream. For example, a 2-channel decoder can naturally play a 2-channel
AC-3 content. But it is also, required to render a downmixed, 2-channel
version of any multichannel AC-3 content.

Will it satisfy your comment if I add a sentence that no special
considerations are needed for the offer/answer mode of SDP?

Regards,
Brian

---
Brian Link
Dolby Laboratories, 100 Potrero Ave., San Francisco, CA 94103
phone: 415-558-0324  fax: 415-863-1373
email: bdl at dolby.com   alt email: link at ieee.org
 

-----Original Message-----
From: Colin Perkins [mailto:csp at csperkins.org] 
Sent: Saturday, January 15, 2005 6:57 AM
To: Link, Brian
Cc: avt at ietf.org
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
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt