[AVT] RE: Comments on draft-ietf-avt-rtp-ac3-04.txt

["Link, Brian" <[e-mail]>]

Hi Magnus,

My responses are in-line. On a couple, it would help to have some
clarification. On the BSID issue, I'd like to propose a different
solution: removal.

Please let me know what you think.

Best,
Brian
---
Brian Link
Dolby Laboratories, 100 Potrero Ave., San Francisco, CA 94103
phone: [phone]  fax: [phone]
email: [e-mail]   alt email: [e-mail]
 
 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]] 
> Sent: Monday, May 30, 2005 2:24 AM
> To: [e-mail]; Link, Brian
> Subject: Comments on draft-ietf-avt-rtp-ac3-04.txt
> 
> Hi Brian
> 
> I have reviewed the updated version and basically think it is fine. 
> However I have the following comments. I think only two are 
> really significant and probably should be addressed or at 
> least discussed before going to working group last call.
> 
> 1. Clarification on how to determine when the next frame 
> starts. I think one should add a sentence clarifying how one 
> determines where the next frame begins in payloads with FT=0. 
> After looking at the codec specification I determined from 
> the bit-stream syntax that the "frmsizecod" in the syncinfo 
> block provides this information for each frame. However I 
> think one should point out that one actually on a payload 
> depacketizer level has to go in and read these bits to 
> determine the length of the AC-3 frame and thus determine 
> where the next starts.
> 
> I would suggest the following text to be added to section 4.1 
> after figure 4.
> 
> "When receiving AC-3 payloads with FT=0 and more than a 
> single frame (NF  > 0), a receiver needs to use the 
> "frmsizecod" field in the synchronization information 
> (syncinfo) block in each AC-3 frame to determine the frame's 
> length. That way a receiver can determine where the next 
> frame will start."
> 

It's okay with me to add this sentence. I wouldn't have thought it was
necessary because the RTP receiver just needs to pass the payload
contents in a buffer to the AC-3 decoder. All AC-3 decoders can parse
frame boundaries, so there is no need to pass frames one at a time. Why
is it useful to add?

> 2. The limitation on BSI in section 5.1. Why is BSI limited 
> to not be greater than 8? As the RTP payload format provides 
> the parameters to negotiate this if using offer/answer two 
> peers can determine the highest BSI value supported by the 
> receiver. Thus one could in the future use the same payload 
> format for updated bit-stream formats as long as the do not 
> violate the basic requirements this payload format is built 
> on (frmsizecod field present, 5/8th is decodable).
> 
> So please clarify if there is any problem you foresee with 
> above proposal. Otherwise I would recommend that the 
> following sentence is simply removed: "Values greater than 8 
> MUST NOT be used with this payload format."
> 

That sentence is a logical conclusion from the requirement to follow the
ATSC spec and it's requirement that AC-3 has a value of 8. Also, all
AC-3 decoders are required to support BSID = 8. I now don't think the
sentence is necessary.

In fact, I've concluded that including BSID as a required parameter is
redundant with the use of the media subtype of 'ac3'. I'd like to remove
all the text about BSID and using SDP to negotiate the value. Any
decoder that can accept content from an RTP stream using the 'ac3'
subtype must be capable of decoding BSID = 8, and therefore is capable
of decoding any bit streams valid under the AC-3 spec.

It is the case the BSID values of 9 and 10 have been used in the past
for a now-defunct technology. Values above 10 are going to be used for
Enhanced AC-3, but a different media subtype will be used for that.

Do you have any objection to deleting all language about BSID?

> 
> Editorial comments:
> 
> E1: The bit-numbering in figure 3 is missalinged. Both the 
> tens and single numbers needs one space in the beginning.
> 

Okay.

> E2. Section 5.1, Encoding consideration.
> Please remove the current two sentenced and replace it with "Framed". 
> See section 4.8 in the following draft:
> 
> http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-04.txt
> 

Is "Framed" correct? From the draft you pointed to: "Additional out of
band
      information is needed to interpret the data properly..." The
information is in band, in the AC-3 bit stream.

Also, why is it desirable to remove the sentences about using the AC-3
format and the payload format? Maybe this is obvious, and I'm just
missing it. 

> E3. Section 7: I would like to reorder the text in the 
> paragraph for better clarify.
> 
> "The general congestion control considerations for 
> transporting RTP data apply to AC-3 audio over RTP as well, 
> see RTP [RFC3550], and any applicable RTP profile (e.g. [RFC3551]).
> 
> AC-3 encoders may use a range of bit rates to encode audio 
> data, so it is possible to adapt network bandwidth by 
> adjusting the encoder bit rate in real time or by having 
> multiple copies of content encoded at different bit rates.  
> Additionally, packing more frames in each RTP payload can 
> reduce the number of packets sent and hence the overhead from 
> IP/UDP/RTP headers, at the expense of increased delay and 
> reduced error robustness against packet losses."
> 

Okay.

> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> 

-----------------------------------------
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt