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

From: Rob Lanphier <[email-masked]>
Date: Wed, 19 Dec 2001 16:33:00 -0800

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:[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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Dec 2001 19:43:39 -0500

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

---

From: Dave Singer <[email-masked]>
Date: Wed, 19 Dec 2001 17:51:35 -0800

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

-- 
David Singer
Apple Computer/QuickTime

---

From: "Lim, Young-Kwon" <[email-masked]>
Date: Fri, 21 Dec 2001 17:24:48 +0900

Dear Rob and all,

> AMR audio in a file, then what is the interaction between the a=mpeg4-iod:

I don't agree with you that this draft preclude mixing. Non MPEG-4 stream
can be handled by MPEG-4 terminal as a private data stream if the sender and
the receiver can understand it.

From the MPEG-4 terminal point of view, AMR is a private content which is
not a normative part of MEPG-4 standard. If you want to use MPEG-4 video
with AMR audio, then AMR audio should be a part of MPEG-4 scene described by
BIFS, and OD as a private data stream. Then, the session will start from IOD
containig pointers to all of the neccessary streams.

> version of this draft that is available for IETF review?

I don't think there is archive, but the reflector is still alive and
working.
draft-singer-mpeg4-ip-03.txt is the latest version equivalent to FDIS in
MPEG world.

Sincerely,
Young.

---

From: Rob Lanphier <[email-masked]>
Date: Fri, 21 Dec 2001 01:20:25 -0800 (PST)

Hi Young,

Comments inline

On Fri, 21 Dec 2001, Lim, Young-Kwon wrote:
> Rob wrote:
> > 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?
>

Why should the AMR come out on the wire wrapped in a bunch of MPEG-4
stuff?  That just prevents an RTSP/RTP/AMR implementation from doing
anything with that stream, even though it's perfectly capable of dealing
with AMR.

Here's the dilemma that we (RealNetworks) have as implementors.  We're
trying to provide an SDK which generically provides RTSP/RTP, and allows
plugins that implement any datatype (including MPEG-4) to take advantage
of the infrastructure provided.

This should work, and in fact, does work in our systems.  However, to
comply to this draft requires some very unnatural things as far as our SDK
is concerned.  Because of the way that IODs are handled, the SDK needs to
become "IOD" aware in a way that it shouldn't need to.  Based on the
presense of this datatype-specific header, the way that RTSP is done is
altered.

Now, having datatypes that alter the RTSP behavior is o.k.....so long as
it's done generically.  The technique that is used should work not only
for MPEG-4 Systems, but should work for SMIL, or Flash, or SVG or HTML or
any other format that wants to be a "metatype", which controls the timing
and layout of other media streams.

So, that's the foundation for a proposal I made earlier on the MMUSIC list
(which I'll forward to this list).  The idea is to change the a=mpeg-iod
line to a=root (or something along those lines).  I'll forward that
proposal momentarily.

Rob

---

From: "Zvi Lifshitz" <[email-masked]>
Date: Fri, 21 Dec 2001 12:17:48 +0200

Dear Rob,

I think there is some misunderstanding regarding this IOD.

An implementation doesn't have to wrap AMR, or any stream type, with a bunch
of MPEG-4 stuff if it doesn't want to. Your server doesn't need to produce
the IOD if it aims for a player that doesn't expect it. Moreover, a non
MPEG-4 aware player can safely ignore the IOD sent by the server and rely
solely on the traditional RTSP/SDP stuff. However, MPEG requires the IOD to
be produced by a server complying with ISO/IEC 14496-8 so that MPEG-4
players who do expect it find it there and proceed successfully.

This is done mainly for supporting advanced content based on MPEG-4. Now if
you ask why MPEG-4 and not SMIL or others, well, MPEG is about making
standards. Application consortiums, like ISMA, for instance, will pick the
standards they find most proper. The question which is the best standard to
pick deserves, and has been received, a fairly thorough discussion.

Regards,

z
soon the whole world will STREAM
==================================================================
Zvi Lifshitz                      Phone +972(2)679-4788
[email-masked]         Fax +972(2)679-4789
Optibase Ltd.                 GSM: +972(54)461-787  (+972-LI-IM1-RTP)
http://www.optibase.com   US voice mail/fax  +1(206) 888-4149
==================================================================
Come see us at:
IIR's IP Multicasting Conference, Holiday Inn Victoria hotel, London
January, 22nd - 23rd, 2002

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Rob Lanphier
Sent: Friday, December 21, 2001 11:20 AM
To: Lim, Young-Kwon
Cc: CURET Dominique FTRD/DMI/REN; 'Colin Perkins';
[email-masked]; [email-masked]
Subject: Re: [AVT] RE: Comments on draft-singer-mpeg4-ip-03.txt

Hi Young,

Comments inline

Rob

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Dec 2001 10:08:28 -0500

>containig pointers to all of the neccessary streams.

You're assuming that we want to include non-MPEG4 content in an MPEG4
session. I'm more concerned with the other direction: it's not clear 
how we can include MPEG4 content in a session managed by RTP/RTSP/SIP.

Colin