Subject: [AVTCORE] What does "same codec+configuration" mean?

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 11 Mar 2016 21:36:11 +0100

Hi,

According to BUNDLE spec, two bundled m= lines can share the same PT
value only if such a PT value points to the same codec name + codec
configuration.

What does "codec + configuration" mean? Some codecs have specific
parameters, some parameters may be optional, and AFAIK there are some
parameters that don't need to be fully negotiated by both endpoints.

May I get some examples and be pointed to the appropriate spec?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Mar 2016 15:55:24 +0100

> May I get some examples and be pointed to the appropriate spec?

So if one reads the bundle specification it says the following:

10.1.2.  Payload Type (PT) Value Reuse

    Multiple bundled "m=" lines might represent RTP based media.  As all
    RTP based media associated with a BUNDLE group belong to the same RTP
    session, in order for a given payload type value to be used inside
    more than one bundled "m=" line, all codecs associated with the
    payload type number MUST share an identical codec configuration.
    This means that the codecs MUST share the same media type, encoding
    name, clock rate and any parameter that can affect the codec
    configuration and packetization.
    [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
    attribute values must be identical for all codecs that use the same
    payload type value.

So identical a=rtpmap and a=fmtp lines would meet this criteria.

However, two different m= blocks configuring a particular PT for a codec 
could possibly use different values for an optional parameter that can 
be received correctly by either configurations.

Codecs that can produce different encoding bit-rates can in many cases 
be used at different bit-rates and fulfil this requirement.

The underlying issue is that what is identical codec configurations are 
codec specific. Thus hard to write a precise definition of it.

Does this help?

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 22 Mar 2016 17:13:39 +0100

2016-03-22 15:55 GMT+01:00 Magnus Westerlund <[email-masked]>:
> could possibly use different values for an optional parameter that can be
> received correctly by either configurations.
>
> Codecs that can produce different encoding bit-rates can in many cases be
> used at different bit-rates and fulfil this requirement.
>

It helps, and I'm sorry since I missed the above text in BUNDLE spec.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 23 Mar 2016 13:46:28 +0100

> So identical a=rtpmap and a=fmtp lines would meet this criteria.

This is becoming so hard to manage:

Offer by Firefox 48:

  m=audio 49706 UDP/TLS/RTP/SAVPF 109 9 0 8
  a=rtpmap:109 opus/48000/2
  a=fmtp:109 maxplaybackrate=48000;stereo=1
  a=rtpmap:9 G722/8000/1
  a=rtpmap:0 PCMU/8000
  a=rtpmap:8 PCMA/8000

  m=video 61083 UDP/TLS/RTP/SAVPF 120 126 97
  a=rtpmap:120 VP8/90000
  a=fmtp:120 max-fs=12288;max-fr=60
  a=rtpmap:126 H264/90000
  a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
  a=rtpmap:97 H264/90000
  a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1

Answer by Chrome 51:

  m=audio 61998 UDP/TLS/RTP/SAVPF 109 9 0 8
  a=rtpmap:109 opus/48000/2
  a=fmtp:109 minptime=10; useinbandfec=1
  a=rtpmap:9 G722/8000
  a=rtpmap:0 PCMU/8000
  a=rtpmap:8 PCMA/8000

  m=video 9 UDP/TLS/RTP/SAVPF 120
  a=rtpmap:120 VP8/90000

Obviously they both interop at opus and VP8 level, so let's see codecs
definition:

1a) opus in Firefox:

  a=rtpmap:109 opus/48000/2
  a=fmtp:109 maxplaybackrate=48000;stereo=1

1b) opus in Chrome:

  a=rtpmap:109 opus/48000/2
  a=fmtp:109 minptime=10; useinbandfec=1

So I must assume that maxplaybackrate, stereo, minptime and
useinbandfec are optional params for opus, or that their default
values (if omitted) match those values, so both codecs+configuration
are the "same".

2a) VP8 in Firefox:

  a=rtpmap:120 VP8/90000
  a=fmtp:120 max-fs=12288;max-fr=60

2b) VP8 in Chrome:

  a=rtpmap:120 VP8/90000

Here also I assume that max-fs and max-fr are optional parameters that
do not prevent both offered codec+configuration to match.

3a) G722 in Firefox:

  a=rtpmap:9 G722/8000/1

3b ) G722 in Chrome:

  a=rtpmap:9 G722/8000

Do they match? Is "1" the default value for the 'encoding' field in a
rtpmap entry?

4) H264 in Firefox:

  a=rtpmap:126 H264/90000
  a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1

  a=rtpmap:97 H264/90000
  a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1

Since Firefox offers two H264 codecs I must assume they are, indeed,
different codecs. So it seems that "packetization-mode=1" make them
different (which also means that its default value is not 1). Right?

This is terribly complex and unmanageable. And this requires the SFU
developer to become an expert in codec specific parameters (regardless
the SFU won't decode media).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 24 Mar 2016 16:27:30 +0100

> different (which also means that its default value is not 1). Right?

I've clarified this:

https://tools.ietf.org/html/rfc6184#section-6

  6.2.  Single NAL Unit Mode

   This mode is in use when the value of the OPTIONAL packetization-mode
   media type parameter is equal to 0 or the packetization-mode is not
   present.  All receivers MUST support this mode.

-- 
Iñaki Baz Castillo
<[email-masked]>