Re: [MMUSIC] WGLC on draft-ietf-mmusic-decoding-dependency-02

[Thomas Schierl <schierl at hhi.fhg.de>]

Hi Jean-Francois,

see my comments below.

Jean-Francois Mule wrote:
> Here are some comments on draft-ietf-mmusic-decoding-dependency-02.
>
> 1) Technical comments/questions:
>
> - can you explain why the scope is limited to decoding dependencies of
> the same media types?

The problem of indicating dependencies between m-lines of the same media
type was raised during the specification of the RTP palyoad format for
SVC video. All mechanisms in the draft are built for exactly this
purpose. Indicating any other kind of dependency is out of scope of this
draft and should be addressed in other drafts. There are already
mechanisms for indicating dependencies like lip sync in the original
grouping draft. I cannot see any overlapping in characteristics of
dependencies described in this draft to dependencies between different
media types or media/FEC. The latter issue has already been discussed
with FECFRAME folks on MMUSIC list.

> > The SDP grouping of Media Lines of different media types
> > is out of scope of this memo.
> Are there specific issues that led to excluding this from the scope?  If
> yes, having a sentence or two would be beneficial. 
> What problems would we have if some folks were to use this 'depend'
> attribute to mean rendering dependency? For example, render video stream
> only if you render the audio stream.

This draft focuses on dependencies related to the coding process of the 
same media type, which is the case for layered or multi description 
codecs when transported and offered/declared as different media 
descriptions. Including rendering would be out of the scope and would 
mean re-writing of many sections of the draft. Since this draft is 
required by the payload for SVC and we have timing constraints for this 
topic, I would suggest to keep the focus.

> - the examples in section 6.4 must have some explanation in plain
> english of how to interpret the depend attribute value (agree with Ali
> there)

I will include this in the version for the IESG.

> - p9: "All media streams MUST contain at least one Operation point."
>                         ^ in a decoding dependency group

ok

> 2) Nits
> - informative text
> As you get the ID ready for publication, you may want to take another
> pass at some of the informative text that you developed to justify the
> draft in the first place.  For example:
> "  At present, SDP and its extensions lack
>    the means to express such a usage relationship."
> => this should be removed or replaced with something like: This document
> defines an SDP extension to indicate such a decoding dependency.

yes, I will take this into account.

> - 'm='-line vs. media description or SDP media description
> The issue is that a media description includes not only the m= line but
> also others such as media attributes which are also important. SDP says:
> "Each media description starts with an "m=" field and is terminated by
> either the next "m=" field or by the end of the session description."
> This is terminology but it is sometimes important in the text.

Ok, it makes sense not to talk about m= lines, but to use the term media
description in the draft. I will take the following into account.

> For example, 
> 	- page 8:
> > The dependency signaling is only feasible between media descriptions
> > described with an "m="-line and with an assigned media identification
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  Implies media description == m=line
> > attribute ("mid"), as defined in [RFC3388].  All "m=" lines grouped
> > according to this specification MUST have the same media type.
> Just say something like:
> The dependency signaling is only feasible between media descriptions
> with an assigned media stream identification attribute ("a=mid:").

ok

>    - page 9:
> > All "m=" lines grouped
> > according to this specification MUST have the same media type.
> s/"m=" lines/media descriptions
>
> - page 9: s/ an IETF standard's track document/ an IETF standards track
> document



Thanks,
Thomas



--
Thomas Schierl
--------------
Fraunhofer HHI




_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic