957198 - SDP support for additional H.264 parameters

Status: NEW

(Core :: WebRTC: Signaling, defect, P3)

Description

[Adam Roach [:abr]]

To properly negotiate and declare our H.264 capabilities, we need to add the parameters described in http://tools.ietf.org/html/rfc6184#section-8.2 to our offer/answer handling.

Comment 1

[Adam Roach [:abr]]

On a first pass analysis, SIPCC seems to include support for most H.264-related parameters, so the bulk of this work may be plumbing through the values to the H.264 codec rather than any real SDP work. A quick summary:

Already Supported:
  - deint-buf-cap
  - level-asymmetry-allowed
  - max-br
  - max-cpb
  - max-dpb
  - max-fs
  - max-mbps
  - packetization-mode
  - profile-level-id
  - redundant-pic-cap
  - sprop-deint-buf-req
  - sprop-init-buf-time
  - sprop-interleaving-depth
  - sprop-max-don-diff
  - sprop-parameter-sets

Not Currently Supported:
  - in-band-parameter-sets
  - max-rcmd-nalu-size
  - max-recv-level
  - max-smbps
  - sar-supported
  - sar-understood
  - sprop-level-parameter-sets
  - use-level-src-parameter-sets

Notably, all H.264 SDP parameters are considered optional, so the decision about whether we want to implement these last few hinges on whether we think they will be useful for our use cases.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

RFC 6184 added support for asymmetric video levels. 

A bunch of the not-supported options were added in RFC 6184 (3984 bis); it looks like nothing other than level-asymmetry-allowed was added from RFC 6184.   in-band-parameter-sets is useful for gateway compatibility as many legacy H.264 endpoints don't support sprop-parameter-sets.

Comment 3

[Adam Roach [:abr]]

Per an IRC conversation with Randell, the only new parameters that we're likely to be interested in are in-band-parameter-sets and maybe max-rcmd-nalu-size.

Comment 4

[Adam Roach [:abr]]

Randell: given that H.264 has landed and appears to largely work, I'm assuming this is a dupe of some other bug somewhere, but I can't find it. Can you verify my assumption; and, if you know offhand where this work was done, dupe this bug to it? Thanks!

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

No, these are values we'd like to support eventually (in particular in-band-parameter-sets (actually useful) and one or two more (and perhaps level-asymmetry-allowed - we parse it, but I don't think it's processed - and some of the other fancy level-asymmetry values - however, I don't know if the equipment we may end up talking to ever implemented to level asymmetry stuff at all).

Comment 6

[Adam Roach [:abr]]

It seems very unlikely that I'll have an opportunity to work on WebRTC platform development for the foreseeable future. I'm unassigning this bug so that someone else might pick it up.

Comment 7

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.