Subject: [AVT] MPEG-4 over IP draft: a=mpeg-iod (fwd)

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

Here's my earlier proposal....
---------- Forwarded message ----------
Date: Thu, 29 Nov 2001 17:07:06 -0800
From: Rob Lanphier <[email-masked]>
To: "[email-masked]" <[email-masked]>,
     "[email-masked]" <[email-masked]>,
     "[email-masked]" <[email-masked]>
Subject: MPEG-4 over IP draft: a=mpeg-iod

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

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

---

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

[Rob Lanphier:]

> discrete streams (if ever).

[Reply:]

This is the first time I hear this interpretation. I don't believe this is
the intention of the text.

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

---

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

Rob, I replied to this before.

>subsequent SETUP and PLAY methods for the sources in that stream.

absolutely wrong.  The IOD may well identify RTP sessions within the 
same SDP session.  Only if the IOD specifies a remote OD URL or ES 
URL would you be re-directed.

Given this mis-understanding, I am not sure whether I ought to 
respond to the rest of this.

>  Rather,

-- 
David Singer
Apple Computer/QuickTime

---

From: Rob Lanphier <[email-masked]>
Date: Fri, 21 Dec 2001 12:19:41 -0800 (PST)

> respond to the rest of this.

Ah, sorry...should have replied to you the first time around.  Let me make
this clear.

It's not that the client is prohibited from issuing SETUP and PLAY, but
rather, from an efficiency standpoint, it's often unwise to.  Moreover,
that one little line can completely change the semantics of everything
else in the presentation.

For example, it could be that there are 30 videos in a presentation which
are meant to be played sequentially.  A non-IOD aware implementation would
try to play all 30 videos in parallel.  Not a very good experience.
Ideally, there should be a generic flag to the RTSP/RTP/SDP part of the
stack which indicates "whoa, don't go setting everything up just yet",
because that's useful to more than just MPEG-4.

Moreover, if there were some indication of which streams are "time=0"
streams (i.e. those streams which should be initialized immediately) that
would be even better.  A good example of where this would be useful is in
the case of a slideshow with audio.  The first slide and the audio track
could be marked "time=0", and the rest of the images would not be marked.
The non-IOD aware application which supports the image format and the
audio stream would just show the first slide and play the audio, rather
than trying to put all of the slides up on the screen simultaneously.

This is not to say that the IETF should try to develop a whole new
synchronization formats, because we've got enough of those.  Rather, we
should just realize that MPEG-4 IODs fall into a broader
category of "synchronization formats" and that we should have generic
hooks in SDP for that.

Rob

---

From: Dave Singer <[email-masked]>
Date: Fri, 21 Dec 2001 12:29:51 -0800

>because that's useful to more than just MPEG-4.

OK, this touches on an area that we explicitly did not attack in this 
first round:  dyanmism in the streams themselves.  There are several 
areas here:  what if streams are not really *needed* until later? 
What if streams are 'floating' and should start interactively?  What 
if streams must be added or removed?  The first case the terminal 
might optimize by realizing that the no node in the scene is asking 
for the stream yet, and be lazy about the SETUP.  I don't think we 
need a flag at the SDP level.  Neither of the other cases are handled 
within an SDP session;  separate sessions are needed at the moment.

>than trying to put all of the slides up on the screen simultaneously.

The slides should be in a timed stream of RTP images.  MPEG-4 is not 
going to 'warp' the stream timing here, since that can't be done in 
the RTP envelope we're in.

>category of "synchronization formats" and that we should have generic

I'd much rather (for the moment) treat the IOD as ancillary data for 
some of the streams, which the terminal might want to get.  The 
streams themselves are mostly self-describing.
-- 
David Singer
Apple Computer/QuickTime