Re: [AVT] WGLC on draft-ietf-avt-rfc3016bis

["Bont, Frans de" <[e-mail]>]

Hi Keith,

Thanks for your extensive review.
Please find our comments below in-line.

Best regards,
Frans

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of DRAGE,
> Keith (Keith)
> Sent: 2010 Dec 06 12:59 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [AVT] WGLC on draft-ietf-avt-rfc3016bis
>
> I've reviewed the document, comments as follows
>
> 1)      This document has inherited a considerable problem from the previous
> RFC 3016, in that much of that document is written with strange RFC 2119
> usage, and pretty much entirely in the passive case. How readers assess
> conformance to this document I don't know. However, given that anyone who is
> going to implement these parts of RFC 3016 will presumably already have done
> so, I have limited my comments on this part to areas where I think the
> requirements are totally unclear, and specifically tagged them as on the
> existing text. If anyone thinks it would be useful to go further, then I can
> certainly submit a large number of further comments on the existing text, but
> they are not included here.

The purpose of this document is mainly to correct some errors in RFC 3016, and to provide an extension to signal the presence of MPEG Surround audio data. Indeed existing users will use this, so we see no need to go much further with the level of the comments.

> 2)      (Editorial). Abstract.
>
>    Comments are solicited and should be addressed to the working group's
>    mailing list at [e-mail] and/or the author(s).
>
> Delete this text. I don't know why people include this in an internet-draft in
> the first place, given that it states the obvious, and it is not needed in the
> RFC.

Will be deleted, Roni made the same comment.

> 3)      (Existing text). Section 1.1
>
>    The fragmentation rule recommends not to map more than one VOP in an
>    RTP packet so that the RTP timestamp uniquely indicates the VOP time
>    framing.  On the other hand, MPEG-4 video may generate VOPs of very
>    small size, in cases with an empty VOP (vop_coded=0) containing only
>    VOP header or an arbitrary shaped VOP with a small number of coding
>    blocks.  To reduce the overhead for such cases, the fragmentation
>    rule permits concatenating multiple VOPs in an RTP packet.  (See
>    fragmentation rule (4) in section 3.2 and marker bit and timestamp in
>    section 3.1.)
>
> The use of recommends here is a pseudo quote from later in the document. It
> would be better if it was a real quote as in the previous paragraph, thus it
> should be modified as follows,
>
>    The fragmentation rule "Different VOPs SHOULD be fragmented into different
> RTP packets" is made
>    so that the RTP timestamp uniquely indicates the VOP time
>    framing.  On the other hand, MPEG-4 video may generate VOPs of very
>    small size, in cases with an empty VOP (vop_coded=0) containing only
>    VOP header or an arbitrary shaped VOP with a small number of coding
>    blocks.  To reduce the overhead for such cases, the fragmentation
>    rule permits concatenating multiple VOPs in an RTP packet.  (See
>    fragmentation rule (4) in section 3.2 and marker bit and timestamp in
>    section 3.1.)

Agreed.

> 4)      (Existing text). Section 1.2
>
>    in RTP transmission there is no need for the last two features.
>    Therefore, these two features MUST NOT be used in applications based
>    on RTP packetization specified by this document.  Since LATM has been
>    developed for only natural audio coding tools, i.e., not for
>    synthesis tools, it seems difficult to transmit Structured Audio (SA)
>    data and Text to Speech Interface (TTSI) data by LATM.  Therefore, SA
>    data and TTSI data MUST NOT be transported by the RTP packetization
>    in this document.
>
> Section 1.2 is an introductory section. Therefore it is inappropriate to start
> introducing RFC 2119 language at this stage. As far as I can see, these
> requirements are not elsewhere in the document, so we will need to create a
> place for them. I suggest a new section 3 immediate before the existing
> section 3, and renumber accordingly (given that the numbering of the existing
> RFC 3016 has not been preserved.

A new section 3 will be created.

> Similar considerations apply to the following two paragraphs:
>
>    For transmission of scalable streams, audio data of each layer SHOULD
>    be packetized onto different RTP streams allowing for the different
>    layers to be treated differently at the IP level, for example via
>    some means of differentiated service.  On the other hand, all
>    configuration data of the scalable streams are contained in one LATM
>    configuration data "StreamMuxConfig" and every scalable layer shares
>    the StreamMuxConfig.  The mapping between each layer and its
>    configuration data is achieved by LATM header information attached to
>    the audio data.  In order to indicate the dependency information of
>    the scalable streams, the signaling mechanism as specified in
>    [RFC5583] SHOULD be used (see section 4.2).

This paragraph will be added to the new section 3.

>    For MPEG-4 Audio coding tools, as is true for other audio coders, if
>    the payload is a single audio frame, packet loss will not impair the
>    decodability of adjacent packets.  Therefore, the additional media
>    specific header for recovering errors will not be required for MPEG-4
>    Audio.  Existing RTP protection mechanisms, such as Generic Forward
>    Error Correction (RFC 5109 [RFC5109]) and Redundant Audio Data (RFC
>    2198 [RFC2198]), MAY be applied to improve error resiliency.

As this paragraph doesn't contain RFC 2119 language we feel that this paragraph can stay in the introduction.

> 5)      Section 1.3.
>
> I first looked for this at the end of the document, in some kind of appendix,
> because that is where I expected to find it, and I wanted to check this first.
> So my first comment is that while there is no rule on this, I would prefer it
> to appear at the end of the document.

Will be moved to the end of the document.

> 6)      Section 1.3.
>
> I do not think the list as currently drafted gives a very good indication to
> existing implementors at what they need to look at in order to update their
> implementations. This should be redrafted to identify key things that are
> revised implementation will need to look at. For example:
>
>    o  The audio parameter "SBR-enabled" is not defined within RFC 3016
>       but used by 3GPP
>
> should become something like:
>
>    o  The use of an audio parameter "SBR-enabled" is now defined in this
> document, which is used by 3GPP implementations [informative reference to 3GPP
> specification here].

Agreed.

> 6)      Section 1.3. For the text:
>
>    Furthermore some comments have been addressed and signaling support
>    for MPEG surround [23003-1] was added.  It should be noted that the
>    audio payload format described here has some known limitations.  For
>    new system designs RFC 3640 [RFC3640] is recommended.
>
> Remove the contruct "It should be noted that the". It is mixing material that
> could be confused as normative with definitely informative material.

Agreed.

> It is also unclear how RFC 3640 is recommended, as the reference is
> informative, and this is the only place it is referenced. I assume you mean
> that new implementations would not be using this document at all. But that
> surely should be called out in the Abstract of this document.

The last two sentences of this paragraph will be moved to the Abstract.

> 7)      Section 2 (Editorial)
>
>    This memo makes use of terms, specified in [14496-2], [14496-3], and
>    [23003-1].  In addition, the following terms are used in this
>    document and have specific meaning within the context of this
>    document.
>
> Change to:
>
>    This document makes use of terms, specified in [14496-2], [14496-3], and
>    [23003-1].  In addition, the following terms are used in this
>    document and have specific meaning within the context of this
>    document.

Agreed.

> 8)      Section 3 (Existing text)
>
>    This section specifies RTP packetization rules for MPEG-4 Visual
>    content.  An MPEG-4 Visual bitstream is mapped directly onto RTP
>    packets without the addition of extra header fields or any removal of
>    Visual syntax elements.  The Combined Configuration/Elementary stream
>    mode MUST be used so that configuration information will be carried
>    to the same RTP port as the elementary stream. (see 6.2.1 "Start
>    codes" of ISO/IEC 14496-2 [14496-2]) The configuration information
>    MAY additionally be specified by some out-of-band means.  If needed
>    for an H.323 terminal, H.245 codepoint
>    "decoderConfigurationInformation" MUST be used for this purpose.  If
>    needed by systems using Media Type parameters and SDP parameters,
>    e.g., SIP and RTSP, the optional parameter "config" MUST be used to
>    specify the configuration information (see 5.1 and 5.2).
>
> The abbreviation "e.g." means for example, and "MUST" can never be and
> example. I supect the example here is only the string "e.g., SIP and RTSP" so
> I suggest that this bit is placed in parenthesis, as follows: "(e.g., SIP and
> RTSP)"

You are correct, the draft will be updated accordingly.

> 9)      Section 3.2 (Existing text). In the following text:
>
>   (5) It is RECOMMENDED that a single video packet is sent as a single
>    RTP packet.  The size of a video packet SHOULD be adjusted in such a
>    way that the resulting RTP packet is not larger than the path-MTU.
>    Note: Rule (5) does not apply when the video packet is disabled by
>    the coder configuration (by setting resync_marker_disable in the VOL
>    header to 1), or in coding tools where the video packet is not
>    supported.  In this case, a VOP MAY be split at arbitrary byte-
>    positions.
>
> remove the mix of the word "note" with normative text. I suggest:
>
>   (5) It is RECOMMENDED that a single video packet is sent as a single
>    RTP packet.  The size of a video packet SHOULD be adjusted in such a
>    way that the resulting RTP packet is not larger than the path-MTU.
>    If the video packet is disabled by
>    the coder configuration (by setting resync_marker_disable in the VOL
>    header to 1), or in coding tools where the video packet is not
>    supported, a VOP MAY be split at arbitrary byte-
>    positions.

Agreed.

> 10)     Section 3.3 (Existing text. In the following text:
>
>    When concatenating more than one video packets into an RTP packet,
>    VOP header or video_packet_header() shall not be placed in the middle
>    of the RTP payload.  The packetization as in (b) is not allowed by
>    criterion (2) due to the aspect of the error resiliency.  Comparing
>    this example with Figure 2(d), although two video packets are mapped
>    onto two RTP packets in both cases, the packet-loss resiliency is not
>    identical.  Namely, if the second RTP packet is lost, both video
>    packets 1 and 2 are lost in the case of Figure 3(b) whereas only
>    video packet 2 is lost in the case of Figure 2(d).
>
> is the "shall" here denoting a requirements (in which case it should be
> capitalised and replaced with "MUST", and moved to a section that is not
> titled "Example") or is it denoting something else, e.g. an impossibility, in
> which case change the modal auxiliary to something else.

The requirements used here are already listed in (old) section 3.2 ".. is prohibited by criterion of 3.2".
The "shall not be placed" will be replaced by "are not allowed to be placed".

> 11)     Section 4.2, 1st paragraph:
>
>    Payload Type (PT): The assignment of an RTP payload type for this new
>    packet format is outside the scope of this document, and will not be
>    specified here.  It is expected that the RTP profile for a particular
>    class of applications will assign a payload type for this encoding,
>    or if that is not done then a payload type in the dynamic range shall
>    be chosen by means of an out-of-band signaling protocol (e.g., H.245,
>    SIP, etc).  In the dynamic assignment of RTP payload types for
>    scalable streams, a different value SHOULD be assigned to each layer.
>    The dependency relationships between the enhance layer and the base
>    layer SHOULD be signaled as specified in [RFC5583].  An example of
>    the use of such signaling for scalable audio streams can be found in
>    [RFC5691].
>
> Write the above new text in the active, i.e. "In the dynamic assignment of RTP
> payload types for scalable streams, the server SHOULD assign a different value
> to each layer. The server SHOULD signal ...".

Agreed.

> Under what circumstances does the "SHOULD" not apply. It is good practice when
> using "SHOULD" to give guidance tot he reader of the conditions under which it
> is safe to ignore the requirement. Otherwise may implementors treat the word
> as a straight option and ignore it.

Will be changed into "SHALL".

> It is also noted that a requirement specifying the assignment of the payload
> type is inconsistent with the first sentence, which says "assignment of an RTP
> payload type for this new packet format is outside the scope of this
> document". This sentence will therefore need to be altered.

Will be changed into "... is outside the scope of this document, and will only be restricted here.".

> 12)     Section 4.2 (Existing text). Is the following meant to be normative:
>
>    Timestamp: The timestamp indicates the sampling instance of the first
>    audio frame contained in the RTP packet.  Timestamps are recommended
>    to start at a random value for security reasons.
>
> It is currently drafted as such, but "recommended" is lower case.

Will be made upper case.

> 13)     Section 4.3 (Existing text). What is the meaning of the final
> sentence:
>
>    If it cannot, the audioMuxElement MAY
>    be fragmented and spread across multiple packets.
>
> As written it is telling me I have an option to fragment it and spread it
> across multiple packets. Is that what is meant.

Indeed, there is no option. The "MAY" will be changed into "SHALL".

> 14)     Section 5.1. The following text:
>
>    Note, any unspecified parameter MUST be ignored by the receiver to
>    ensure that additional parameters can be added in any future revision
>    of this specification.
>
> has the word "MUST" mandatory requirement, following the word "note" which
> many people interpret as informative. Assuming a mandatory requirement is
> meant, delete the word "Note". The text should also be redrafted in the
> active, e.g.:
>
>    The receiver MUST ignore any unspecified parameter, to
>    ensure that additional parameters can be added in any future revision
>    of this specification.

Agreed.

> This is also a registration section. Surely normative requirements on the
> implementation should be elsewhere in the document, so I suggest this text is
> moved to another more appropriate section.

We checked RFC 3640 and it has this text also in the registration section. Not sure where else to place this text.

> 15)     Section 5.1.
>
>    Published specification:
>
>       The specifications for MPEG-4 Visual streams are presented in ISO/
>       IEC 14469-2 [14496-2].  The RTP payload format is described in RFC
>       XXXX.
>
> Why not just say: "The RTP payload format is described in this document."
>
> Same change for the following two entries, and also in section 5.3.

Agreed.

> 16)     Section 5.3, 5.4.1.3 and 5.4.1.4. This document does not define the
> coding of the SBR-enabled parameter. I get the impression from reading the
> document that it is defined elsewhere, but no reference is made to the point
> where it is defined. That would surely need to be a normative reference.

The "SBR-enabled" parameter is defined as a boolean parameter in 5.3. Do we miss your point?

> 17)     Section 5.3.
>
>    Note, any unspecified parameter MUST be ignored by the receiver to
>    ensure that additional parameters can be added in any future revision
>    of this specification.
>
> See comments on similar text at the start of section 4.1.

And our response at 14)

> 18)     Section 5.3 (Existing text):
>
>   Required parameters:
>
>       rate: the rate parameter indicates the RTP time stamp clock rate.
>       The default value is 90000.  Other rates MAY be specified only if
>       they are set to the same value as the audio sampling rate (number
>       of samples per second).
>
> Change "specified" to "indicated". The AVT working group is the specifier.

Agreed.

> 19)     Section 5.3 (Existing text). There are a number of lower case "shall"
> here. Do these constitute requirements. How is the reader of this
> specification expected to understand and interpret them.
>
> If they are not requirements, then change them.

Will be made upper case.

> 19)     Section 5.3 (existing text)
>
>       MPS-profile-level-id: a decimal representation of the MPEG
>       Surround Profile Level indication as defined in ISO/IEC 14496-3
>       [14496-3].  This parameter indicates the MPEG Surround profile and
>       level that the decoder must be capable in order to decode the
>       stream.
>
> What is the meaning of the final sentence?

This sentence will be modified into.
"This parameter indicates the support of the MPEG Surround profile and level by the decoder to be capable to decode the stream."

> 20)     Section 5.3 (existing text)
>
>      ptime: RECOMMENDED duration of each packet in milliseconds.
>
> Why is this a requirement. Hows does an implementation conform to it.

"RECOMMENDED" will be removed.

> 21)     Section 5.3
>
>      If this parameter is set to 0, a decoder SHALL expect that SBR is
>       not used.  If this parameter is set to 1, a decoder SHOULD
>       upsample the audio data with the SBR tool, regardless whether SBR
>       data is present in the stream or not.
>
> First sentence is not written as a conformable requirement. What does the
> decoder need to do to conform? For the second sentence, see comments earlier
> on use of SHOULD.

The SHALL and SHOULD will be replaced by MAY and CAN, respectively.

> 22)     Section 5.3
>
>       If the presence of SBR can not be detected from out-of-band
>       configuration and the SBR-enabled parameter is not present, the
>       parameter defaults to 1 for an SBR-capable decoder.  If the
>       resulting output sampling rate or the computational complexity is
>       not supported, the SBR tool may be disabled or run in downsampled
>       mode.
>
> Change "may" to "can" to indicate that it is definitely not a conformance
> requirement.

Agreed.

> 23)     Section 5.4.1.3
>
>    In this example, the presence of SBR can not be determined by the SDP
>    parameter set.  The clock rate represents the core codec sampling
>    rate.  An SBR enabled decoder SHOULD use the SBR tool to upsample the
>    audio data if complexity and resulting output sampling rate permits.
>
> This section is entitled "Example". Such sections ideally should not include
> conformable requirements. So if this is a requirement then move it somewhere
> else. Also comments elsewhere about the use of SHOULD also apply here.

The "SHOULD" will be replaced by "can", as it is not a requirement.

> 24)     Section 5.4.1.4
>
>    In this example, the clock rate is still 24000 and this information
>    should be used for RTP timestamp calculation.  The value of 24000 is
>    used to support old AAC decoders.  This makes the decoder supporting
>    only AAC understand the HE AAC coded data, although only plain AAC is
>    supported.  A HE AAC decoder is able to generate output data with the
>    SBR sampling rate.
>
> Change "should be" to "is" to avoid confusion with a conformable requirement.

Agreed.

> 25)     Section 6.
>
>    This memo defines additional optional format parameters to the Media
>    Type "audio" and its subtype "MP4A-LATM", as defined in RFC XXXX.
>    The Media Type parameters are defined in sections 5.1 and 5.3 of RFC
>    XXXX.
>
> Just say "sections 5.1 and 5.3 of this document".

A similar comment was made by Roni.
The proposal is to change it into.

   This document updates the media subtypes "MP4A-LATM" and "MP4V-ES"
   from RFC 3016.  The new registrations are in Section 6.1 and
   Section 6.3 of this document.

> 26)     Section 6.1.
>
>    This memo defines the following additional optional parameters which
>    SHOULD be used if SBR or MPEG Surround data is present inside the
>    payload of an AAC elementary stream.
>
> We do not need a SHOULD (or any other RFC 2119 language in relation to an IANA
> considerations section.
>
> I suspect this is just superfluous, and not a real conformable requirement on
> implementations.

(old) Sections 6.1 and 6.2 will be removed, see a comment made by Roni.

> 27)     Section 6
>
> An IANA considerations section should basically consists of a set of
> instructions to IANA as to what they need to include in their tables. See
> http://www.iana.org/protocols/
>
> I cannot ascertain from this section whether they need to do work.
>
> Are there any existing RFC 3013 registrations where the reference needs to be
> updated?
>
> Are there any of these parameters that actually need registration?

See our remark at 25)

>
>
> regards
>
> Keith
>
>
> ________________________________
>
>         From: Roni Even [mailto:[e-mail]]
>         Sent: Tuesday, November 23, 2010 2:00 PM
>         To: [e-mail]
>         Cc: DRAGE, Keith (Keith); [e-mail]
>         Subject: WGLC on draft-ietf-avt-rfc3016bis
>
>
>
>         Hi,
>
>         I would like to start a working group last call on
> http://tools.ietf.org/html/draft-ietf-avt-rfc3016bis-01
>
>
>
>         RTP Payload Format for MPEG-4 Audio/Visual Streams
>
>
>
>         The WGLC will end on December 13th , 2010
>
>         Please review the draft and send comments to the list
>
>
>
>         Note that section 1.3 and 1.4 discuss the changes from RFC3016
>
>
>
>         Roni Even
>
>         AVT co- ass=MsoNormal>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.