Some WebRTC implementations such as Pion are unhappy if the
profile-level-id isn't returned with a compatible profile as the
RFC requires. Let's try to reform it
In practice, the correct way to do this would be to not use caps
intersection, but to instead implement the correct RFC compliant
SDP O/A negotiation of formats.
Include a unit test written by Philippe Normand
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9031>
As specified formally in RFC8851
Each rid description is placed in its own caps field in the structure.
This is very similar to the already existing extmap-$id sdp<->caps
transformations that already exists.
The mapping is as follows:
a=rid:0 direction ';'-separated params
where direction is either 'send' or 'recv'
gets put into a caps structure like so:
rid-0=(string)<"direction","param1","param2",etc>
If there are no rid parameters then the caps structure is generated to
only contain the direction as a single string like:
rid-0=(string)direction
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1760>
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
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1410>
