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

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Dec 2001 10:46:54 -0500

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

---

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

>  > - Characteristic 2.4 (MUST implement a default scheme) is 

The generic draft now exists and should be identified explicitly.

>  > - Characteristic 2.6: where is the mapping for RFC 3016 defined?

This was a promised contribution for MPEG, but I am not aware of the 
promise being fulfilled.

>>    draft-curet-avt-rtp-mpeg4-flexmux-02.txt. Which is correct?

I believe that the FlexMux draft should be referred to, and the 
explicit names in this document removed.

>>    Systems will interact with this. Similar with a=mpeg4-iod-xmt

I think that this needs clarification.  If your MPEG-4 session needs 
to provide an IOD (which it normally does), then this is how you do 
it.  Since it refers to more than one media stream potentially, it 
can't be a media-stream attribute;  that's why it's global.  It's 
unfortunate that this means that you can only have one MPEG-4 session 
in an SDP description.  I'd love to hear of better ways around.

Of course, the payload formats absolutely allow you to convey all you 
need to in SDP and the payloads without an IOD.  I would tend to use 
these mechanisms myself...

>>    the URL in double quotes?

The phrase "enclosed in double-quotes" should probably be replaced by 
a reference to a spec which says how URLs are passed in SDP...

>>    mpeg4..., to be consistent with RFC 3016 and the file formats (e.g. in

I think there was and is a real attempt to distinguish MPEG-4 (the 
system) from MP4 (the file format).  I think we are losing this, 
however.

>>    will be used for streaming with RTP.

Move it to FlexMux.

-- 
David Singer
Apple Computer/QuickTime

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Dec 2001 00:40:43 -0500

Dave,

Mostly agree. A couple of minor comments inline...

>in an SDP description.  I'd love to hear of better ways around.

The fid extension, maybe (draft-ietf-mmusic-fid-05.txt)? It will get pretty
ugly though...

>system) from MP4 (the file format).  I think we are losing this, 

That's not a bad idea, provided we make the distinction explicit in the
registrations.

>>>    will be used for streaming with RTP.

Cheers,
Colin

---

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

Dear Dave,

Thank you for providing answers. I mostly agree with you. Most of them seems
to be editorial. Some comments are inlined.

> The generic draft now exists and should be identified explicitly.

I agree that this was not updated properly. Revised sentence in FDIS is as
follows:

"To achieve a base level of interoperability, and to ensure that any ISO/IEC
14496 stream may be carried, all receivers should implement a generic
payload format defined in "draft-ietf-avt-mpeg4-multisl-00.txt" as default
RTP payload mapping scheme. Any new payload format should be a configurable
subset of the generic payload format."

> This was a promised contribution for MPEG, but I am not aware of the

I neither believe this would be specified.

> explicit names in this document removed.

Sorry. They not properly updated, too. In FDIS, they are all removed.

> these mechanisms myself...

Naturally, MPEG-4 session cannot interact with non MPEG-4 streams. So, the
only way is to include them as a private stream in MPEG-4 session. Exactly
same way we use DLLs. They can be handled by the higher layer applications
who know both. I agree that in this case we need to define the access points
in MPEG-4 scene. That may be a minor burden.

> a reference to a spec which says how URLs are passed in SDP...

Would you provide an exact reference I can include?

> system) from MP4 (the file format).  I think we are losing this,

We need to distinguish streaming MPEG-4 streams from download MP4 file.

> >>    will be used for streaming with RTP.

Agree.

Unfortunately, FDIS is already approved. So, we cannot make any technical
changes but can make editorial changes before hand the document to ISO
secriteriat. And there is no timeframe for the final editing. So, my only
concern to adopt all of the changes we agreed is whether they are all
editorial or not.

Oliver, are you following this? What is your opinion?

Sincerely,
Young.

---

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

--> "Lim, Young-Kwon" writes:
...
>in MPEG-4 scene. That may be a minor burden.

The main reason for RFC 3016 was to allow MPEG-4 streams to interact with
non-MPEG4 content. This framework needs to explicitly allow for this, and
inclusion of non-MPEG4 content in MPEG4 is not sufficient for this.

Colin

---

From: Dave Singer <[email-masked]>
Date: Fri, 21 Dec 2001 10:01:40 -0800

>inclusion of non-MPEG4 content in MPEG4 is not sufficient for this.

I think what Young-Kwon says is only one way to achieve this, and not 
the simplest.  Imagine an SDP file which says

IOD referring to streams 1 and 2
stream with attribute ES-ID = 1
stream with attribute ES-ID = 2
another stream, say GSM audio

the GSM stream is not a member of the MPEG-4 session but is a member 
of the SDP session.  Clearly it should be played synchronized with 
the other content in the same session, just as if it were combined 
with H.263 audio.  The fact that some of the other streams have some 
grouping and ancillary data structures associated with them is 
basically irrelevant.

I know that the traditional MPEG approach is that you either fit 
inside the MPEG world or you can't be used.  I have struggled here to 
make MPEG play better with other specs and standards, and I think 
this is much improved in MPEG-4.  In the case where you are 
signalling and delivering over internet protocols (in this case SDP), 
they are 'on top'.

The reverse case might happen in a set-top box which gets an IOD as 
its 'starter', which in turn (somehow) identifies some of the streams 
as being delivered via SDP/RTP, with others only mentioned in the 
IOD/OD;  then MPEG-4 is 'on top'.

So you *could* add the ES-ID attribute to the GSM stream, add an 
object descriptor which describes it as 'user private' and so on, but 
I don't think you need to unless you need the manipulations (e.g. 
spacial positioning of audio) that MPEG-4 could give you.  Makes 
sense?
-- 
David Singer
Apple Computer/QuickTime

---

From: "Lim, Young-Kwon" <[email-masked]>
Date: Sat, 22 Dec 2001 11:25:03 +0900

Dear Dave and all,

> spacial positioning of audio) that MPEG-4 could give you.  Makes

I think the better way is to assign code points (objectType) to AMR if this
combination seems to be used widely. Any standardization body can ask MPEG
to work on it via liaison letter. This would solve the problem more
organized way.

BTW, you don't need to add ES-ID attribute. We can use URL field in ESD to
point RTP channel (IP address + port number) in this case.

Sincerely,
Young.

---

From: "Zvi Lifshitz" <[email-masked]>
Date: Sat, 22 Dec 2001 18:14:25 +0200

[Colin Perkins:]

> inclusion of non-MPEG4 content in MPEG4 is not sufficient for this.

[Reply:]

I'm not sure that "this framework needs to explicitly allow for this". This
framework is for MPEG-4 sessions based on MPEG-4 systems. For inclusion of
MPEG-4 stream in other frameworks other frameworks are provided.

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