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

From: Dave Singer <[email-masked]>
Date: Wed, 2 Jan 2002 17:26:46 -0800

At 11:25 +0900 12/22/01, Lim, Young-Kwon wrote:
>Dear Dave and all,
>
>
>>
>>  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?
>
>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.

But both of these are attempts to fit things inside the mpeg-4 
framework.  I still maintain that it's perfectly OK to have streams 
in the SDP session that are simply not present in the mpeg-4 session.
-- 
David Singer
Apple Computer/QuickTime

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

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 2 Jan 2002 17:48:14 -0800 (Pacific Standard Time)

On Wed, 2 Jan 2002, Dave Singer wrote:
> >I think the better way [to have AMR co-exist with MPEG-4 video] 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.
> >

I fully agree with Dave that this is how things should be.  Dave, are you
arguing that this is the way things are (given the current state of
proposed packetizations), or the way they should be?

Rob

---

From: Dave Singer <[email-masked]>
Date: Wed, 2 Jan 2002 18:18:18 -0800

>proposed packetizations), or the way they should be?

I maintain that this is how they are.  Nothing in any spec I am aware 
of says that if an IOD is present, it talks about *all* the streams 
in the SDP session.
-- 
David Singer
Apple Computer/QuickTime

---

From: Jeff Ayars <[email-masked]>
Date: Thu, 03 Jan 2002 11:41:36 -0800

At 06:18 PM 1/2/2002 -0800, Dave Singer wrote:
>I maintain that this is how they are.  Nothing in any spec I am aware of 
>says that if an IOD is present, it talks about *all* the streams in the 
>SDP session.
>--

I'm a little lost on this thread but I do have a comment on the draft.

3.1 states:

                  a=mpeg4-iod [<location>]

                   location:  In an RTSP session, this is an optional 
attribute. If not
                   supplied, the IOD is retrieved over the RTSP session by 
using
                   DESCRIBE with an accept of type application/mpeg4-iod.

I read this to say a normal RTSP conversation would look like this:

C->S:   DESCRIBE <url> RTSP/1.0
         Accept: application/sdp

S->C:  RTSP 200 OK
         Content-Type: application/sdp
         Content-Length: ...
         <sdp contents>

< client parses SDP, finds a=mpeg4-iod or a=mpeg4-iod-xmt >

C->S:   DESCRIBE <same url> RTSP/1.0
         Accept: application/mpeg4-iod  <or application/mpeg4-iod-xmt>

S->C:   RTSP 200 OK
         Content-Type: application/mpeg4-iod <or application/mpeg4-iod-xmt>
         Content-Length: ...
         <iod>

< client parses IOD, does some mapping of SDP media entries to presentation 
described by IOD, decides what to setup when, etc..>

Do I have that right?

If so, why the double describe?  Why not just a single describe with all 
description formats in the Accept header?

C->S:   DESCRIBE <same url> RTSP/1.0
         Accept: application/mpeg4-iod, application/mpeg4-iod-xmt, 
application/sdp

Is it the case that SDP is insufficient to describe everything mpeg4-iod 
can?  Is mpeg4-iod insufficient to describe everything SDP can?

If both formats describe the presentation to different application layers 
(is that the right distinction?), to Rob Lanphier's initial question on the 
draft, why a specific extension for mpeg4?  Why not a generic mechanism for 
additional presentation descriptions using a single new SDP attribute 
that's not mpeg4 specific?

JEff

---

From: Dave Singer <[email-masked]>
Date: Thu, 3 Jan 2002 11:46:00 -0800

At 11:41 -0800 1/3/02, Jeff Ayars wrote:
>>I maintain that this is how they are.  Nothing in any spec I am 
>>aware of says that if an IOD is present, it talks about *all* the 
>>streams in the SDP session.
>>--
>
>                   supplied, the IOD is retrieved over the RTSP 
>session by using
>< client parses IOD, does some mapping of SDP media entries to 
>presentation described by IOD, decides what to setup when, etc..>
>
>Do I have that right?
>
>If so, why the double describe?  Why not just a single describe with 
>all description formats in the Accept header?
>
>Is it the case that SDP is insufficient to describe everything 
>mpeg4-iod can?  Is mpeg4-iod insufficient to describe everything SDP 
>can?

Yes, and Yes.  The envisaged scenario was a normal RTSP 
server/client, where you initially get the SDP.  That alerts you to 
the IOD, and if you are a terminal that needs an IOD, you can now get 
it.

>
>If both formats describe the presentation to different application 
>layers (is that the right distinction?), to Rob Lanphier's initial 
>question on the draft, why a specific extension for mpeg4?  Why not 
>a generic mechanism for additional presentation descriptions using a 
>single new SDP attribute that's not mpeg4 specific?
>
>JEff

I'd be fine with that.  I just don't know of one.
-- 
David Singer
Apple Computer/QuickTime

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 3 Jan 2002 14:44:30 -0800 (Pacific Standard Time)

> the IOD, and if you are a terminal that needs an IOD, you can now get

But there's nothing wrong with a normal RTSP server immediately returning
application/mpeg4-iod if the client has indicated mpeg4-iod is an
acceptable DESCRIBE response.  Why the extra SDP step?

> I'd be fine with that.  I just don't know of one.

My initial suggestion was that we create one:

a=root:<uri>

...where the URI can be a data URL, or an external reference.

Rob

---

From: Dave Singer <[email-masked]>
Date: Thu, 3 Jan 2002 14:56:34 -0800

>acceptable DESCRIBE response.  Why the extra SDP step?

The complete session is described by SDP.  In it some of the streams 
belong to an MPEG-4 session which is described (additionally) by an 
IOD.  The IOD tells us, for example, which streams to start decoding 
with (e.g. which is the root scene if there are several scene 
streams).  SDP tells us port mappings and so on.  They are 
complimentary.  We decided against returning them both at once as 
then you'd have to have a multipart message, which seemed 
un-necessarily complex.  But maybe I am wrong.

>...where the URI can be a data URL, or an external reference.

What is the content of the URI?  How do I know whether I need this or 
what I will get if I access it?

The point of the mpeg-4-iod tag was explicitly the warning that some 
of the streams are structured as part of an MPEG-4 session, and to 
decode them right you probably need to know the IOD.
-- 
David Singer
Apple Computer/QuickTime

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 3 Jan 2002 19:45:00 -0800 (Pacific Standard Time)

> un-necessarily complex.  But maybe I am wrong.

I would agree that multi-part MIME would be needlessly complex.  Perhaps
this is a matter of taste, but I don't like the idea that DESCRIBE can be
issued twice *on the same URL* and returns two totally different classes
of information (not just different formats).  It seems that the iod should
always have a different URL than the content (it's fine to make it a
relative URL, the same way stream ids are), thus the location field in the
a=mpeg4-iod line should not be optional.

> What is the content of the URI?  [How do I know] what I will get if I
> access it?

In the case of a data URL, the media type is embedded in it.  In the case
of HTTP, it would be in the GET response, and in the case of RTSP, it
could be dictated by the Accept: header.

I do see your point, though.  It would be nice to have the type right
there all of the time.  New proposal:

a=root <uri> [<type>]

The type would be a MIME type.  It would be worthwhile to discuss whether
this would be allowed:

a=root http://foo.com/bar application/mpeg4-iod
a=root http://foo.com/bar application/mpeg4-iod-xmt
a=root http://foo.com/bar application/smil
a=root http://foo.com/bar application/svg
a=root http://foo.com/bar text/html

...i.e. give a whole bunch of options, and leave it to the client to sort
out.

> How do I know whether I need this [...]?

That is a fine question, *regardless* of what the syntax is (current
proposal or any new proposal), unless you are saying that the
"a=mpeg4-iod" header *must* be present whenever streams marked "audio/mp4"
and "video/mp4" are served.

Under my proposal, I guess one could add a "a=needroot" flag on the
individual streams that need this (under the respective m= lines).
Alternately, we could extend this a little further, and allow for multiple
roots (i.e. multiple IODs):

...
a=root <id> <uri> [<type>]
a=root <id> <uri> [<type>]
m=audio....
a=needroot <id>
m=video...
a=needroot <id>

The id would be a concise identifier valid within the document, and would
allow the audio stream and the video stream to be bound to separate IODs
if that was necessary for whatever reason.

> decode them right you probably need to know the IOD.

Which streams?  All of the MPEG-4 streams?  Some of them?  What if some
streams are

Rob

---

From: Dave Singer <[email-masked]>
Date: Fri, 4 Jan 2002 09:42:54 -0800

>a=mpeg4-iod line should not be optional.

I think I might like this idea, but it's worth noting that doing two 
describes with different Accepts seems reasonably clear.  However, I 
understand that this might be seen as two ways of delivering the same 
information.  The problem with requiring the URL, is that it 
ambiguates the URL.  Should I (a) issue another Describe or (b) fetch 
the data at the given URL?  I guess the form of the URL would have to 
tell you.  If it's relative, you can use the same connection.  If 
it's RTSP, open that URL and do a Describe/accept-IOD.  If it's HTTP 
or FTP, do a get of that URL...

would this fly better?

>and "video/mp4" are served.

No, it is present if MPEG-4 *systems* is used for the presentation, 
and you need to know (minimally) the initial OD and BIFS streams, and 
maybe the profile/levels (though these are also tagged on the 
streams), and possibly extension descriptors attached to the IOD.

>Which streams?  All of the MPEG-4 streams?  Some of them?  What if some

cut off in the middle?

you don't need to know;  all you really need to know is that an 
MPEG-4 systems session comprises some of the streams in the session.
-- 
David Singer
Apple Computer/QuickTime