Subject: [MMUSIC] Comments on draft-schierl-mmusic-layered-codec-00

From: Jonathan Lennox <[email-masked]>
Date: Fri, 07 Jul 2006 13:25:31 -0400

I've reviewed this draft, and while I generally like the mechanism, I have
some concerns.  I don't think they necessarily imply any changes to the
draft's mechanisms, but some points should be clarified.

The draft implies -- though I don't think it requires -- that every distinct
layer of a media stream is sent in its own RTP session, and furthermore that
a layer of a media stream is sent in only one RTP session.

In some operational modes, these are reasonable assumptions; however, there
are other modes where they are not true.

Consider, for example, a layered stream being sent across two RTP sessions,
one of which is QoS-reserved, the other best-effort.  In such an
environment, a sender will generally want to put as many of the stream's
lower layers into the QoS-reserved session as possible, up to the session's
reserved bandwidth, and then put the rest of the stream into the best-effort
session.

Since video bandwidths can vary a great deal, in such an architecture the
mapping of stream layers to RTP sessions will vary a great deal.  It's not
clear to me how draft-scheirl-mmusic-layered-codec would signal this type of
stream usage over SDP.

The dependency ID graph in this case is straightforward: the best-effort
session depends on the QoS-assured session.  However, should either, or any,
of the sessions have a=resolution or a=framerate parameters?  And if only
some of the layers that may be sent in a session are fgs-scalable, should
either of the sessions have a=fgscapability?

--
Jonathan Lennox -- Layered Media
[email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Thomas Schierl" <[email-masked]>
Date: Sat, 8 Jul 2006 14:06:57 +0200

Jonathan,

Thanks for reviewing the draft.
Comments inline:

> -----Original Message-----
> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Friday, July 07, 2006 7:26 PM
> To: [email-masked]
> Subject: [MMUSIC] Comments on draft-schierl-mmusic-layered-codec-00
> 

That is not completely correct. The draft implies that one ore more layers
of the layered media may be transported within one transport stream, thus
multiple dependencies on other transport streams may come up.

The draft in its first version describes dependencies on media (transport)
stream level only.

> reserved bandwidth, and then put the rest of the stream into the best-

Thanks, great input! This point is currently not considered.

> clear to me how draft-scheirl-mmusic-layered-codec would signal this type

If I correctly understand, you want a feature which allows changing the
mapping of media layers to transport streams during the session lifetime?
Assuming all media layers are using the same payload format and all
transport sessions include the signaling for the full layered media stream
up to the highest operation point, this may be generally possible.

SDP allows for signaling a multiplexing point for distinguishing between
media streams: The transport port, which may be extended by a bunch of
multicast addresses. Thus currently the only feasible identification of a
transport stream is the media stream itself. From my point of view, your
approach would require an additional multiplexing point if you want to
describe the layers in general (e.g. for one media type) first and then
distinguish the mapping on different transport streams, which may be
indicated not as an additional media stream, but as transport stream itself
for the media stream. 

Otherwise we need to describe both RTP sessions of your example as different
media streams, each identified by a port. The question is now how to
independently describe the media layers itself (once for the two media
streams), which should be transferred in the different transport streams
defined by the different media streams? I'm a little bit afraid that the
definition for the media layers used within this approach would become dirty
in the sense of SDP. 

Anyway, it seems to me that this may be a starting point for an interesting
discussion. And we will discuss this in more detail in the next version of
the draft.

Maybe we should first clear this point before going into details of media
layer description.

Regards,

Thomas

_______________
Thomas Schierl
Fraunhofer HHI
[email-masked]

--
Meet us at 

OC&I 2006 and NOC 2006: 10.-13.7.06 at HHI Berlin, Germany
IFA: 1.-6.9.06, Berlin, Germany