sdp/rtph264pay: Handle level-asymmetry-allowed

commit 9dc445cf4f7ec0da757156d1727ac74da3f835e5 (HEAD -> rtppay_fix, thiblahute/rtppay_fix)
Author: Thibault Saunier <tsaunier@igalia.com>
Date:   Thu Dec 2 13:32:33 2021 +0000

    rtph264pay: Handle 'profile' field
    
    In order to allow "level-asymmetry-allowed" we now handle a new
    "profile" field, which as the same semantics as the "profile" field in
    H.264 stream so that we can force payloaded stream to have the right
    format when using the `gst_sdp_media_get_caps_from_media` to set caps
    filter after the payloader. This allows a simple negotiation in standard
    RTP negotiation based on SDPs (like webrtc) for that particular case,
    closely respecting the specs.

commit 6c0c3235e0c98337e2aef67f926c5939fbc36ab9
Author: Thibault Saunier <tsaunier@igalia.com>
Date:   Fri Dec 3 01:45:49 2021 +0000

    sdp: Handle level-asymmetry-allowed for H264 streams
    
    The ["level-asymmetry-allowed"] field states that the peer wants the
    profile specified in the "profile-level-id" fields but doesn't care
    about the level. To express this in GStreamer caps term, we add a
    "profile" field in the caps, which reuses the usual "profile" semantics
    for H.264 streams and, and remove "profile-level-id" and
    "level-asymmetry-allowed" fields.
    
    ["level-asymmetry-allowed"]: https://www.iana.org/assignments/media-types/video/H264

---

EDIT: Outdated

The level-asymmetry-allowed field is defined as an SDP parameter to basically let us know that the H.264 level is not mandatory. In rtph264pay we need to take that information into account and negotiation if upstream is not producing what downstream recommends.

We still ensure that the profiles are respected, but downstream the level that we be advertise in profile-level-id will not be the one the stream actually is, I don't see any way around that and it shouldn't be a big deal in practice.