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

[Colin Perkins <[e-mail]>]

My understanding is that this is the final version of the framework draft,
and that is will be published by MPEG as is. Accordingly, the fact that it
is not consistent with the other payload formats is a real problem.

Colin




--> Rob Lanphier writes:
>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