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

[Magnus Westerlund <[e-mail]>]

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

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


Editorial comments:

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

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

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


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]

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