Re: [AVT] RE: Comments on draft-singer-mpeg4-ip-03.txt

[Rob Lanphier <[e-mail]>]

Hi Dominique,

I think what Colin is saying (and what I'd agree with) is that the 
techniques used in this draft preclude mixing MPEG-4 streams with non 
MPEG-4 streams in a generic way.  For example, if one has MPEG-4 video and 
AMR audio in a file, then what is the interaction between the a=mpeg4-iod: 
and the AMR audio?

Is the 4on2andIP list archived somewhere?  Is there a more up-to-date 
version of this draft that is available for IETF review?

Thanks,
Rob

At 06:16 PM 12/19/01 +0100, CURET Dominique FTRD/DMI/REN wrote:
>Dear all,
>
>My understanding is that the goal of this framework draft is to give a
>global picture, from the MPEG-4 point of view, for the recommended RTP
>payloads to carry MPEG-4 signals.
>
>This framework draft is not a new payload. It recognises the MultipleSL
>payload and the Flexmux payload.
>
>As the MultipleSL draft payload and the Flexmux draft payload have recently
>evolved, and as the framework draft does not seem to have been updated, it
>is right and obvious that the framework draft may be inconsistent with the
>recent draft payloads.
>
> >From a FlexMux payload's author point of view, as I am not directly one of
>the authors of the framework draft, I didn't feel the necessity informing
>the authors (David & Young-Kwon) of the framework, on the evolution of the
>details of the Flexmux draft payload.
>
>The text of the framework draft is quite difficult to finalize, as it tries
>to present a digest of the different payloads. Inconsistency is difficult to
>avoid in such cases. As far as SDP declaration is concerned, may be should
>we give the exact details within the different payloads, without repeating
>(which is always inconsistent!) such details in the framework. It is also
>certainly possible to have the IANA considerations only within that
>framework, and get rid of the IANA considerations in the draft payloads?
>
>I think that keeping consistent our drafts is one task of the 4on2andIP Ad
>Hoc group.
>
>your comments are welcome
>
>yours sincerly
>
>dominique
>
>-----Message d'origine-----
>De : Colin Perkins [mailto:[e-mail]]
>Envoyé : mercredi 19 décembre 2001 16:47
>À : [e-mail]
>Cc : [e-mail]
>Objet : Comments on draft-singer-mpeg4-ip-03.txt
>
>
>Folks,
>
>I've been asked to forward this discussion to the list. These are my
>comments
>on the MPEG-4 framework draft (draft-singer-mpeg4-ip-03.txt), which I've
>just
>become aware is still under consideration in MPEG.
>
>Colin
>
>
>
>------- Forwarded Message
> > - The restriction in characteristic 2.3 (ISO/IEC 14496 timescale MUST be
>used
> >   as the RTP timescale) is not present in
>draft-ietf-avt-mpeg4-multisl-03.txt
> >   I assume it is implicit, but this should be made explicit.
> >
> > - Characteristic 2.4 (MUST implement a default scheme) is meaningless
>unless
> >   the default is defined.
> >
> > - Characteristic 2.6: where is the mapping for RFC 3016 defined?
> >
> > - Characteristic 2.6 is repeated, the numbering needs to be corrected.
> >
> > - Characteristics 2.7 - 2.9 are inconistent with the FlexMux format in
> >   draft-curet-avt-rtp-mpeg4-flexmux-02.txt. Which is correct?
> >
> > - I'm concerned about the use of the "a=mpeg4-iod:" attribute at the SDP
> >   session level, given that it is not mentioned in the payload format
> >   drafts. This restricts a session description to describing a single
> >   MPEG-4 session, and it is not clear how sessions that do not use MPEG-4
> >   Systems will interact with this. Similar with a=mpeg4-iod-xmt
> >
> > - Are there any encoding considerations for URLs in SDP? Presumably the
> >   URL encoding needs to be performed, which is more than just enclosing
> >   the URL in double quotes?
> >
> > - Characteristic 3.2 informally defines a number of MIME types (mpeg4-sl
> >   and mpeg4-flexmux) which should be defined by reference to their specs.
> >
> > - Characteristic 3.4 would be better included as part of the payload
> >   format, as an a=fmtp parameter.
> >
> > - Characteristic 4.1 contradicts the multi-sl draft, which also defines
> >   "application" as a valid top level MIME type for MPEG4
> >
> > - Characteristic 4.4 contradicts RFC 3016, which uses video/mp4v-es. It
> >   may be better to use mp4... as the prefix for all the MIME types, not
> >   mpeg4..., to be consistent with RFC 3016 and the file formats (e.g. in
> >   4.5 - 4.7).
> >
> > - In 4.8, the mpeg4-flexmux type is registered. This should either be done
> >   as part of the FlexMux payload format, or the registration should be
> >   explicit that this is for the file format, and an alternative format
> >   will be used for streaming with RTP.
> >
> > - You need an IANA considerations section, if this is to be published as
> >   an RFC.
> >
> > - References need updating. If this is to be published as an RFC, there
> >   may be normative dependence on the payload formats..
>------- End of Forwarded Message
>
>_______________________________________________
>Audio/Video Transport Working Group
>[e-mail]
>http://www1.ietf.org/mailman/listinfo/avt


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