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

From: "Link, Brian" <[email-masked]>
Date: Wed, 1 Jun 2005 17:53:49 -0700

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: 415-558-0324  fax: 415-863-1373
email: [email-masked]   alt email: [email-masked]

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, May 30, 2005 2:24 AM
> To: [email-masked]; 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 +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 

-----------------------------------------
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: Magnus Westerlund <[email-masked]>
Date: Thu, 02 Jun 2005 09:49:48 +0200

Hi Brian,

Answer to your questions inline and some new text suggestions.

> frame boundaries, so there is no need to pass frames one at a time. Why

I think this sentence is necessary for receiver implementations that 
actually handle separate ADUs per its design. The RTP payload format has 
fragmentation and aggregation. A logical implementation in software of 
this payload format handles individual AC-3 frames after the 
depacketization, independently if they where transported fragmented or 
aggregated. That way timestamping, handling at start and stop etc is 
more predictable than to have arbitrary large units of varying time 
duration.

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

No, this is clean and clear and will work. Such as you describe BSID and 
how certain larger values has been deprecated I would support the course 
of defining a new media type for any future version of AC-3.

[snip]
> Is "Framed" correct? 

Yes, but based on the discussion regarding 3GPP Timed Text I would 
update it to:

"This media type is framed (see section 4.8 in [34]) and contains binary 
data."

Add reference per below.

 From the draft you pointed to: "Additional out of
> information is in band, in the AC-3 bit stream.

No, the RTP payload format needs RTP sequence numbers, timestamps etc 
from the RTP header. Thus it is framed.

> format and the payload format? Maybe this is obvious, and I'm just

The reason is that this doesn't is what the encoding consideration 
section is for. The media type's encoding consideration is intended to 
tell the outer transport protocol how it needs to handle the data to not 
corrupt it. This is particular important in an email environment when 
all binary content need to be encoded into text, using for example base 
64. This clarifications are not really needed for RTP that always can 
handle binary content and is framed, however as we currently uses a 
shared registry, we need to provide this information.

I would also update the registration section by adding the following 
text first in the media type registration:

    "This registration is done using the template defined in [34] and 
following RFC 3555 [33]."

We should also replace the RTP restriction on usage with something a bit 
more explanatory.

OLD:
Restrictions on usage:

This media type is defined for RTP transport only.

NEW:
Restrictions on usage:

    This media type depends on RTP framing, and hence is only defined for
    transfer via RTP [RFC 3550]. Transport within other framing protocols
    is not defined at this time.

Where the informational references to add are:

     [33] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
          Payload Formats", RFC 3555, July 2003.

     [34] Freed, N. and J. Klensin, "Media Type Specifications and
          Registration Procedures", draft-freed-media-type-reg-04,
          April 2005.

Please note that the above media type registration text proposals are 
coming out of the discussion with people on the ietf-types list. It 
might require some more baking, however I do not hope that. And I think 
this will be good enough for going to WG last call.

Cheers

Magnus Westerlund