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

From: CURET Dominique FTRD/DMI/REN <[email-masked]>
Date: Thu, 20 Dec 2001 08:47:33 +0100

Dera all,

If I may add something on the FlexMux payload spec, 
even if it is not the major subject of this discussion:

David said: 
>That's my main problem with the current FlexMux proposal, 
>that it uses a new clock unrelated to the media clock.

Catherine understood, during her presentation in Salt Lake
City that this had to be clarified:
The FCR is at the FlexMux level what is the OCR at the SL level.

When we go further reading the FlexMux specification:
"The sequence of fmxClockReference time stamps in a FlexMux stream 
constitutes a clock reference stream....... 
Elementary streams may be associated to the time base established 
by this clock reference by referencing the FCR_ES_ID as their 
OCR_ES_ID in the SLConfigDescriptor."

best regards

Dominique

-----Message d'origine-----
De : Dave Singer [mailto:[email-masked]]
Envoyé : jeudi 20 décembre 2001 02:52
À : Rob Lanphier; CURET Dominique FTRD/DMI/REN; 'Colin Perkins'
Cc : [email-masked]; [email-masked]
Objet : Re: [AVT] RE: Comments on draft-singer-mpeg4-ip-03.txt

At 16:33 -0800 12/19/01, Rob Lanphier wrote:
>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?

First, I ought to say that although my name is still on the draft, I 
am in fact no longer the editor...

However, the IOD applies only to the MPEG-4 session.  A real goal of 
mine has been to make sure that the MPEG-4 packings and other uses of 
IETF protocols should be in a way which means that they are *not* 
islands, unable to be used with other content.  That's my main 
problem with the current FlexMux proposal, that it uses a new clock 
unrelated to the media clock.

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

This is, apparently, the latest draft.  I agree with Colin, it needs work.

>
>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:[email-masked]]
>>Envoyé : mercredi 19 décembre 2001 16:47
>>À : [email-masked]
>>Cc : [email-masked]
>>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
>>[email-masked]
>>http://www1.ietf.org/mailman/listinfo/avt
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/avt

-- 
David Singer
Apple Computer/QuickTime

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