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

[Magnus Westerlund <[e-mail]>]

Hi Brian,

Answer to your questions inline and some new text suggestions.

Link, Brian wrote:
>>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?
> 

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.


> 
>>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?
> 

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]
> 
>>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? 

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
> band
>       information is needed to interpret the data properly..." The
> 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.

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

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

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