Subject: [AVT] Comments on the MPEG4-Simple packetization

From: Stephan Wenger <[email-masked]>
Date: Tue, 05 Feb 2002 02:35:07 +0100

Folks,

Recent communication with the authors of the draft encouraged me
to make these comments available to AVT, in order to show that
the draft receives proof-reading.  Please consider this as a review
in the sense the chairs requested.

These comments are relative to draft-ietf-avt-mpeg4-simple.txt

Editorial:

1. Proof-Reading of the References.  I found one problem, reference [5] is
never used although it should be in section 2.11, but there may be more.

2. Headers/Footers do not comply with the normal I-D format.  Please fix.
Page numbers ARE helpful.

3. Structure of Section 2:  This section contains a lot of different 
information
in an order that I do not feel to be natural. I would suggest:

2.1 What does the draft do:
a) Transport a single ES in the form of an AU, a multitude of AUs, or a
single AU fragment in one RTP packet, potentially with interleaving.
Short intro, no details yet.
b) Relies on "Modes", to be defined (references to later sections), explain
clearly that modes are essential (has also to go into the Introduction --
this is something other RTP payloads do not have
c) Has a relationship with multisl and 3016 (reference to later details)
2.2 Payload specification
a) Section 2.9 as an overview
b) section 2.2, 2.3, 2.4, 2.5
2.3 Mapping of MPEG header information
a) section 2.6
b) section 2.7
c) section 2.8

Technical comments

1. non-random timestamp:  (Note: based on recent reflector activity, this
comment and the related concern seems to be void.  Great. Anyway,
I copy here what I wrote to the authors)
Personally, I don't like the concept as it is, and I believe that more 
intelligent
ways out of the problem should be searched, both for the multisl and for the
simple drafts.  But, regardless of my opinion, the non-random timestamp does
open a security hole.  It has to be discussed in the "Security Considerations"
Section that this hole exists, and that it is not problematic for the intended
applications of the draft, or you are in for trouble latest at the IESG 
last call.
(This needs also to be fixed in the multisl draft).

2. The restriction to a single AU fragment per RTP packet prevents Slice-
Interleaving which has been shown to be an extremely efficient error 
resilience
tool in the H.263 research (and, hence, was included in the H.263 test model
and in RFC2429).  It would also facilitate gateway design in such cases in
which large changes of the MTU size can happen, e.g. in wireline/wireless
gateways.  I'm unsure whether the inclusion of a multitude of AU fragments
per RTP packet produces a large set of new problems, but you should
consider it (or write a very good reason into the draft why this was not 
included,
otherwise there will be questions during last call).

3. Timestamp-Issue re B-frames:  (Note: based on private discussions with
one of the author I continue to believe that the presence of the DTS has indeed
little to do with the possibility of decoding B-frames.  I continue to 
believe the
field is redundant, and the mechanism for the DTS reconstruction based on
the regular Timestamp and the in-band information of the video stream is
sufficient.  However, it may be convenient to have a DTS as generated by the
system layer.  If this is the case, then it should be mentioned in the draft
instead of the reason given.  Anyway, here my original comment)
Another thing I don't understand (and which
should go into the draft, because if I don't understand it, there may be 
others,
too).  My understanding is that the MPEG-4 video bit stream is self-contained,
including the timing information for B-frame reproduction.  The reason for 
the DTS
lies deep into the SL-Layer design, but it is, as far as I understand, neither
necessary for the correct media reproduction, nor for the internal works of 
the
payload spec and RTP.  Hence, it looks to me that the DTS is really only there
because it is also present in the multisl draft (which may need it for 
synchronization
reasons or something I don't know).  It may be acceptable to just state 
that the
field is present for no other reason but to keep bit-by-bit synchronicity 
with the
MultiSL draft.  Or, if there is a technical reason, state it.  I don't feel 
the given
rationale compelling -- in particular I believe that the MPEG-4 video bit 
stream IS
self contained even with respect to B frames.

4. The Mode concept:  See above in the editorial section regarding the 
prominent
placements of the Mode Concept description.  My technical problem (which may
be an editorial as well) lies in the fact that you discuss provisions 
regarding the
carrying of video (e.g. presence of DTS) outside a mode discussion, but in the
mainstream document.  Is this a half though-through mode?  Then call it 
like this
and put it into an appendix (or work it out completely and put it into the 
Mode section
itself).  Or is it a collection of constraints people who design a mode for 
video have
to keep in mind?  Then call it like this and move it to an appropriate place.

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