[AVT] Comments on draft-ietf-avt-mpeg4-simple-06.txt

[Colin Perkins <[e-mail]>]

Jan,

I think the MPEG-4 payload format is in good shape now. I have a number of
editorial comments below, mostly trying to tighten the language of the new
interleaving section and clarifying some of the examples. 

Colin




 - Need to make it clear that the interleaving pattern at the bottom of
   page 7 is an example, and that other patterns are possible. Suggest
   changing "Assume that..." to "For example, if we assume that..."

 - The first paragraph of section 3.2.3.2 "Interleaving" is unclear. I
   suggest rewriting it as follows:
	Unless prohibited by the signalled mode, a sender MAY interleave
	Access Units. Receivers that are capable of receiving modes that
	support interleaving MUST be able to decode interleaved Access
	Units. 
   (The last sentance of the original paragraph was redundant with the
   explanation that followed).

 - The second paragraph of section 3.2.3.2 starts "When a sender interleaves
   Access Units, then the transmitter needs to...". This could be rewritten
   as "When a sender interleaves Access Units, it needs to..." 

 - The formula at the top of page 17 has a non-ASCII character, which does
   not display correctly. I assume it should be a minus sign?

 - I find the explanation of the "constantDuration" parameter in the three
   paragraphs following the formula on page 17 to be unclear. I suggest the
   following rewording:

    The MIME parameter "constantDuration" SHOULD be used to signal that
    Access Units have a constant time duration, see section 4.1. 

    If the "constantDuration" parameter is present, the receiver can
    reconstruct the original Access Unit timing based solely on the RTP
    timestamp and AU-Index-delta. Accordingly, when transmitting Access
    Units of constant duration, the AU-Index, if present, MUST be set to
    the value 0. Receivers of constant duration Access Units MUST use the
    RTP timestamp to determine the index of the first AU in the RTP packet.
    The AU-Index-delta header and the signalled "constantDuration" are used
    to reconstruct AU timing.

    If the "constantDuration" parameter is not present, then Access Units
    are assumed to have a variable duration. In this case, the transmitter
    MUST use the AU-Index to encode the index information required for
    re-ordering, and the receiver MUST use that value to determine the
    index of the first AU in the RTP packet. The number of bits of the
    AU-Index field MUST be chosen so that valid index information is
    provided at the applied interleaving scheme, without causing problems
    due to roll-over of the AU-Index field. In addition, the CTS-delta MUST
    be coded in the AU header for each non-first AU in the RTP packet, so
    that receivers can place the AUs correctly in time.

 - Section 4.1 defines the "ConstantDuration" parameter, but the text
   refers to it as "constantDuration". They should be consistant. 

 - In section 3.3.2, the draft should mention that the a=fmtp: line has
   been split for presentation in the RFC, and is actually a single long
   line. Also, "BIFSConfiguration()" should be replaced by an example of
   the hexadecimal string, and the text "BIFSConfiguration() is the
   hexadecimal string as defined in ISO/IEC 14496-1" replaced by "The
   hexadeciaml string in the 'config=' parameter is the result of the
   BIFSConfiguration() function defined in ISO/IEC 14496-1", or similar.

   [Similar comments apply to the examples in the other modes]

 - In section 3.3.3, the draft might say "Interleaving MUST NOT be used 
   with this mode" instead of "there is no support for interleaving". A
   similar comment applies to section 3.3.4 where "optional interleaving"
   could be "OPTIONAL interleaving".

 - In section 3.3.5, "frames MUST not be fragmented" -> "...MUST NOT..."

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