Subject: [MMUSIC] Proposed definition for "same codec configuration"

From: Jonathan Lennox <[email-masked]>
Date: Wed, 31 Jul 2013 07:51:03 -0400

As I mentioned at the mic today, my straw-man proposed definition for "same codec configuration" is:

Two codec configurations are the same if the PT has the same value for the "rtpmap" and "fmtp" SDP parameters.

Known issues with this definition:

Some codecs (notably H.264's sprop-* parameters, and all of Opus's parameters) have fmtp parameters describe behavior of a sender, or else are non-normative indications about the modes that would be most useful but aren't actually necessary to configure a decoder.  So it's overly restrictive to insist that fmtp be identical between all the lines.

Getting this to work would, I think, require analysis in the style of draft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of every codec anyone cares about.

The other issue is whether there are other SDP parameters (presumably ones that are specified in terms of PT) that also need to be considered to be part of the "codec configuration" and needs to be aligned.  Imageattr was proposed as one possibility.
--
Jonathan Lennox
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jul 2013 14:01:29 +0200

> Two codec configurations are the same if the PT has the same value for the "rtpmap" and "fmtp" SDP parameters.

This needs to also include the major type that is included in the m=
line (i.e., "audio" or "video").

> Some codecs (notably H.264's sprop-* parameters, and all of Opus's parameters) have fmtp parameters describe behavior of a sender, or else are non-normative indications about the modes that would b…

I don't believe that the utility provided by allowing the fmtp to be
split in this way outweighs the costs.  It's far simpler if this is
just defined as above.

> Getting this to work would, I think, require analysis in the style of draft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of every codec anyone cares about.

Exactly.  Let's not do that work.  Just doing the work would be hard.
Gaining consensus on it might also cause it to take some significant
amount of time.  If it's super-important, the rfc-to-be for bundle can
be updated.

> The other issue is whether there are other SDP parameters (presumably ones that are specified in terms of PT) that also need to be considered to be part of the "codec configuration" and needs to be…

I don't believe imageattr to be relevant in this case.  If it were
relevant, it would only be because the codec in question didn't signal
resolution in-band, but in that case, fmtp line should contain the
resolution in that case.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 31 Jul 2013 08:33:40 -0400

> line (i.e., "audio" or "video").

Right.

> amount of time.  If it's super-important, the rfc-to-be for bundle can

I'm inclined to agree, unless someone wants to do the work.  (I don't want to do the work.)  But then, I didn't want to do the work for BUNDLE either, and people decided it was important enough that they went ahead and did it.

> resolution in-band, but in that case, fmtp line should contain the

I'm inclined to agree here too.

To a large extent, this overlaps with the work being done in draft-nandakumar-mmusic-sdp-mux-attributes.  It really doesn't matter if we say that parameters have to align per PT because "codec configuration" says so, or whether parameters have to align per PT because the mux-attributes draft says so.

--
Jonathan Lennox
[email-masked]

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 31 Jul 2013 15:40:12 +0200

Agreed !!!

On Wed, Jul 31, 2013 at 2:01 PM, Martin Thomson <[email-masked]>wrote:

> > Some codecs (notably H.264's sprop-* parameters, and all of Opus's
> parameters) have fmtp parameters describe behavior of a sender, or else are
> non-normative indications about the modes that would be most useful but
> aren't actually necessary to configure a decoder.  So it's overly
> restrictive to insist that fmtp be identical between all the lines.
>
> > Getting this to work would, I think, require analysis in the style of
> draft-nandakumar-mmusic-sdp-mux-attributes for every fmtp parameter of
> every codec anyone cares about.
>
> > The other issue is whether there are other SDP parameters (presumably
> ones that are specified in terms of PT) that also need to be considered to
> be part of the "codec configuration" and needs to be aligned.  Imageattr
> was proposed as one possibility.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 31 Jul 2013 18:02:20 +0200

> The other issue is whether there are other SDP parameters (presumably ones that are specified in terms of PT) that also need to be considered to be part of the "codec configuration" and needs to be…
With regard to imageattr, draft-nandakumar classifies it as NORMAL,
which I think means that it only applies to flows that are mapped to the
M-line in which the attribute occurs.

So in the SDP fragment

m=video 1234 RTP/AVPF 97
a=ssrc:9876
a=rtpmap:97 VP8
a=imageattr:97 [x=1280,y=720]

m=video 2345 RTP/AVPF 97
a=ssrc:5432
a=rtpmap:97 VP8
a=imageattr:97 [x=640,y=360]

I think it is clear which flow each imageattr is intended to point to.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Jul 2013 19:05:58 +0200

> The other issue is whether there are other SDP parameters (presumably ones that are specified in terms of PT) that also need to be considered to be part of the "codec configuration" and needs to be…

I have a couple of questions:

When configuring encoder/decoder parameters, regardless of what sort of 
line does it:

AFAIK there is separate encoder/decoder state for each SSRC, right?

So these parameters are just templates that are used for however many 
encoders &/ decoders are set up for that m-line. (Each with a different 
SSRC.)

If you are mapping packets to m-lines by SSRC, then having different 
values per-m-line works.

Now suppose you were mapping packets to m-lines via appid rather than 
SSRC. And suppose initially all packets having appid X have SSID 1111, 
and that is the first appearance of 1111. Then presumably the attributes 
of the m-line corresponding to appid X will determine how the decoder 
are initialized.

Then SSID 1111 is reassigned to appid Y, and is mapped to a different 
m-line. That m-line has different decoder parameters. Should the decoder 
for 1111 be reconfigured?

	Thanks,
	Paul