Subject: [MMUSIC] draft-ietf-mmusic-decoding-dependency-00

From: "Even, Roni" <[email-masked]>
Date: Thu, 29 Nov 2007 16:19:29 +0200

Hi,
I read the draft and I am not sure I understand how the signaling work.
You added the "payload-type-dependency" in section 5.2.2 but it is not specified clearly

The text says: 
"payload-type-dependency", indicates the payload type number of the media stream indicated by the identification-tag, which the payload type number of the media stream in question depends on.

The example did not help me either. In the first example what is the meaning of 1: in the lay and what are dependencies here.

a=depend:95 lay 1:94,195 lay 1:194  

Another issue is how you multiplex two media streams in one media session. Having two payload type in an m-line in the offer allows the answerer to chose one.

In section 6.1 you describe backward compatibility. According to RFC 33888 you should expect a behavior from the answerer who just ignores the group attribute since it does not understand it. In this case the offerer will not get a group attribute in the answer and should take a corrective action, maybe offering H.264 with no SVC. This depends also on what you will get as the m-lines response.

Thanks
Roni Even

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

---

From: "Thomas Schierl" <[email-masked]>
Date: Thu, 29 Nov 2007 16:42:35 -0800

Hi Roni,

First, thanks for providing feedback on the draft !

See my comments below,

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

> From: Even, Roni [mailto:[email-masked]]
> Sent: Thursday, November 29, 2007 6:19 AM
> To: [email-masked]
> Subject: [MMUSIC] draft-ietf-mmusic-decoding-dependency-00
>
> Hi,
> "payload-type-dependency", indicates the payload type number of the
> media stream indicated by the identification-tag, which the payload
> type number of the media stream in question depends on.

Further the text gives the BNF description for the "depend" attribute:

"5.2.2 ...

    depend-attribute     = "a" "=" "depend" ":"
                            payload-type dependency-tag
                            *("," SP payload- type dependency-tag )
                            CRLF
     dependency-tag       = dependency-type 1*( SP identification-tag":"
                            payload-type-dependency )
     dependency-type      = "lay" / "mdc"

   "payload-type", indicates the payload type number, as defined in
   [RFC4566], of the media description in question for which the
   dependencies are indicated in the pair(s) of "identification-tag" and
   "payload-type-dependency" following the "dependency-type".

   "payload-type-dependency", indicates the payload type number of the
   media stream indicated by the identification-tag, which the payload
   type number of the media stream in question depends on.

   The "depend"-attribute describes the decoding dependency.  The
   "depend"-attribute MAY be followed by a sequence of identification-
   tag(s) which identify all related media streams.  The attribute MAY
   be used with multicast as well as with unicast transport addresses.
   The following types of dependencies are defined:
...."

So, the first number (payload-type) indicates the payload type provided
within the media stream. In the example below: "95".
The dependency type gives the type of dependency. In the example below:
"lay".
After that, the mid (identification tag) of the media stream is given, which
the payload type in the current media stream section depends on. In the
example below: "1". The mid is followed by ":" and the corresponding payload
type (payload-type-dependency) the payload type in the current section
depends on. In the example below: 94.
There may be multiple of these combinations of
<mid>:<payload-type-dependency> indicating all media streams with the
corresponding payload types, the payload type in the current session depends
on.
Then, after a comma the dependencies of the next payload type offered in the
current media stream are indicated. In the example: 195. And that one
depends on payload type==194 in media stream with mid==1.

>
> The example did not help me either. In the first example what is the
> meaning of 1: in the lay and what are dependencies here.
>
> Another issue is how you multiplex two media streams in one media
> session. Having two payload type in an m-line in the offer allows the
> answerer to chose one.

Yes, according to the dependencies indicated by the depend attribute, the
client can find out the payload types of the other m-lines, the selected
payload type depends on.

>
> In section 6.1 you describe backward compatibility. According to RFC
> 33888 you should expect a behavior from the answerer who just ignores
> the group attribute since it does not understand it. In this case the
> offerer will not get a group attribute in the answer and should take a
> corrective action, maybe offering H.264 with no SVC. This depends also
> on what you will get as the m-lines response.

Right, for SVC e.g. it is defined, that the h264 baselayer is offered in a
separate session when offered with session multiplexing. We tried to address
this in section 6.1 with
   " ... a node that does not understand DDP
   grouping (either does not understand line grouping at all, or just
   does not understand the DDP semantics) SHOULD respond to an offer
   containing DDP grouping either (1) with an answer that ignores the
   grouping attribute (only possible with "lay" dependency) ..."

Since, we DDP grouping is mandatory for session multiplexing with SVC, the
node that does not understand DDP (it must be an old h264 receiver) would
just include the h264 payload type offer in its answer.

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 30 Nov 2007 12:21:57 +0200

Thanks,
So now I understand 95 depend on 94 and 195 depends on 194. I think you
should state it in the example since I still have problem with the text.
You can give an answer to the offer in the example showing a case where
the answer choose 94 and 95 in the response.

As for payload-type-dependency it is not specified in the ABNF.

On the issue of backward compatibility. The major problem is if the
answerer does not understand this draft it can respond without the group
and select any m-lines depending on how may streams it can support. For
example if you have one audio line and multiple video m-lines the answer
can respond with an audio line and one (which ever he chose, not the
first) of the video m-lines ignoring any unknown parameters in the media
level as long as it can support the media subtype.
I think this is why it will be good to offer the layers with H264-SVC
and have one of the m-line with base line H264. This will enable
backward compatibility. An answerer that do not support DDP and depends
will not support H264-SVC but will chose an H264 payload type.

Roni  

> -----Original Message-----
> From: Thomas Schierl [mailto:[email-masked]]
> Sent: Friday, November 30, 2007 2:43 AM
> To: Even, Roni; [email-masked]
> Subject: RE: [MMUSIC] draft-ietf-mmusic-decoding-dependency-00
> 
> Hi Roni,
> 
> > You added the "payload-type-dependency" in section 5.2.2 but it is
not
> > specified clearly
> Then, after a comma the dependencies of the next payload type offered
in
> the