[AVT] Comments on draft-ietf-avt-mpeg4-simple-04

[Stephen Casner <[e-mail]>]

I have some Last Call comments on draft-ietf-avt-mpeg4-simple-04.
Most are simple editorial changes that I will communicate separately
to the authors.  One in particular that I will point out here (because
others have made the same mistake) is use of the term "sampling
instance" which should be "sampling instant" instead.  "Instant"
identifies a point in time, whereas "instance" refers to a particular
occurrence or example of something.

I have other comments that are more significant.  I don't think any of
them require changes to the protocol, but changes to the text.

  - There was quite a bit of discussion on the MPEG ad-hoc group
    reflector regarding stream state changes resulting in the text in
    3.2.3.4 of this draft.  That mechanism will do a fine job of
    allowing the receiver to identify when packet loss forces decoding
    to stop until the next random access point.  However, it does not
    do anything to make the transmission "reliable".  I would like to
    see a paragraph something like the following inserted as the third
    paragraph of the introduction to make this clear to the reader:

        Some types of MPEG-4 elementary streams include "crucial"
	information whose loss cannot be tolerated, but RTP does not
	provide reliable transmission so receipt of that crucial
	information is not assured.  Section 3.2.3.4 specifies how
	stream state is conveyed so that the receiver can detect the
	loss of crucial information and cease decoding until the next
	random access point is received.  Applications transmitting
	streams that include crucial information should include random
	access points sufficiently often, depending upon the
	probability of loss, to reduce stream corruption to an
	acceptable level.  Such applications may also employ
	additional protocols or services to reduce the probability of
	loss.  These measures include RTP payload formats and
	profiles for forward error correction and retransmission as
	well as resource allocation or preferential service at the
	network layer.

  - Section 2.9 introduces the carriage of auxiliary information
    without any specification of how senders and receivers will agree
    on the format or meaning of that information.  This concerns me
    and I suspect it would concern some folks in the IESG as well.  I
    assume that this mechanism is present to allow partial SL header
    information to be included in the same way that it was in multiSL.
    Such inclusion was acceptable in multiSL and is acceptable here
    also.  It is also fine to defer the specification of the format
    and meaning of this auxiliary data to some other document.
    However, I believe this document must say where the format,
    meaning and signaling of the auxiliary information will be
    specified, and must state auxiliary information MUST NOT be
    transmitted until its format and meaning have been specified and
    its use has been signaled.  To cite an analogous situation, the
    RTP spec defines an RTP header extension mechanism, but requires
    that an RTP profile be defined to specify any extension.

  - Section 3.1 says RTCP SHOULD be used as defined in RFC 1889.  It
    would be helpful to be more specific.  In particular, since there
    is a discussion of timestamps and synchronization a few lines
    earlier, I'd like to see here a mention that timestamps in RTCP
    Sender Reports may be used to synchronize multiple MPEG-4
    elementary streams and also to synchronize MPEG-4 streams with
    non-MPEG-4 streams.

                                                        -- Steve


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