[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Comments on draft-ietf-avt-mpeg4-simple-06.txt
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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt