Subject: MPEG-4 over IP draft: a=mpeg-iod

From: Rob Lanphier <[email-masked]>
Date: Thu, 29 Nov 2001 17:07:06 -0800

Hi all,

A (very belated) comment about singer-mpeg4-ip-03.txt:
http://www.ietf.org/internet-drafts/draft-singer-mpeg4-ip-03.txt

In Section 3, there's discussion about a new line in the SDP when used with 
RTSP/RTP/SDP/MPEG-4 which gives metadata about the IOD (MPEG-4 Initial 
Object Descriptor).

Based on my rudimentary understanding of this, the idea is that an client 
implementation should handle the following line as part of an RTSP DESCRIBE 
response:

a=mpeg4-iod [<location>]

...where <location> is either a URL to a remote source, or (more commonly) 
a data URL.

Based on the presense of the IOD line, the client should *not* issue 
subsequent SETUP and PLAY methods for the sources in that stream.  Rather, 
the IOD should then dictate when the SETUP and PLAY requests occur for the 
discrete streams (if ever).

It seems like this should be a slightly more generic mechanism to trigger 
this behavior.  The media type is already included one way or another in 
the <location> (either by means of the data URL syntax, or by the MIME type 
in the http response, or other scheme specific typing mechanism).

I'm struggling for what the right name is, so I'll use "root" as a working 
name (as in "root" of a tree):
a=root [<location>]

For example, one could do the following:
a=root data:application/mpeg4-iod;base64,3wCcDkiLc7C0qwyGHhSWp....

...or one could also do the following:
a=root data:application/mpeg4-iod-xmt;base64,3wCcDkiLc7C0qwyGHhSWp....

...or if one was feeling a little crazy:
a=root data:application/smil;base64,3wCcDkiLc7C0qwyGHhSWp....

At any rate, any client that supports "root" would be alerted to the fact 
that it needs support for application/whatever in order to stream the file 
properly, regardless of whether it supports mpeg4-iod, mpeg4-iod-xmt, or 
smil as the "whatever" part.

Thoughts?

Rob

---

From: Dave Singer <[email-masked]>
Date: Fri, 30 Nov 2001 16:05:51 -0800

>http://www.ietf.org/internet-drafts/draft-singer-mpeg4-ip-03.txt

whoa yes!  That's now owned by someone else and is an MPEG document.

I think you may be missing something  here.  The 'normal' way to use 
this is to supply the media streams as part of the RTSP session;  you 
still need the IOD to get the profiles/levels values, and maybe the 
Object Descriptors for the OD and BIFS streams.  As a result, we 
envisage two cases here:
-- no URL -- you do another Describe with a different accept
-- URL -- supplies the IOD.

Now, as you say, the IOD may say that the OD and/or BIFS streams are 
remote, and not in the initial RTSP session, but I'd expect that to 
be an unusual case.

>subsequent SETUP and PLAY methods for the sources in that stream. 
>Rather, the IOD should then dictate when the SETUP and PLAY requests 
>occur for the discrete streams (if ever).

No, as I say, usually the streams in that session are the ones you 
want;  the IOD supplies necessary extra setup information that you 
need.

Does this help the discussion?  (Hi Rob!).
-- 
David Singer
Apple Computer/QuickTime