Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
H264 `packetizationMode` array in `RtpCodecCapability` #567
By implementing this, I've found that having
Currently, a browser can expose its H264 capabilities with a single
To be clear: when Firefox generates an SDP with H264 it has two H264 entries, with different payload types and different
@ibc The only scenario that comes to mind in which a browser may want to call
However, the above scenario is not very mainstream. In most cases, I would expect the "common capabilities" algorithm to compute the intersection of the packetization-mode arrays and if there is more than one mode available, utilizes a preference (probably for packetization-mode 1) to select the mode to use, so that only one preferredPayloadType is needed.
added a commit
Jan 11, 2017
referenced this issue
Jan 11, 2017
The reason to not create multiple capabilities entries is because each packetization mode would consume a preferred payload type and payload types are limited. As an array, common scenarios (which only require 0, 1, or 2) would pick their mode and be done as a mutual agreed value which is going to be the most common scenario.
In the rarer simulcast scenarios (or where you must advertise them as separate entries) you can manually assign your own PT value and split these as separate codes with packetization mode if you so choose for each PT. You are not required to use the preferred payload type and can assign your own. Thus if you need on stream with PT 98 with mode 0 and another with PT 99 and mode 1, you are allowed to do that yourself.
So to avoid consuming rare PTs for the common cases and since we can support the other scenario too I suggest nothing should be done and marked as "won't fix". Or maybe clarification and illustrate how this would be handled using the existing API.