New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

H264 `packetizationMode` array in `RtpCodecCapability` #567

Closed
ibc opened this Issue Jun 20, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@ibc
Contributor

ibc commented Jun 20, 2016

By implementing this, I've found that having packetizationMode as an array of integers in the capability codec of H264 is not comfortable at all.

Currently, a browser can expose its H264 capabilities with a single codec capability entry containing packetizationMode: [ 0, 1 ] but the fact is that, depending which value is chosen, that is a different codec+configuration. However, the browser may want to call rtpSender.send() with both codec_A (H264 + packetizationMode: 0) and codec_B (H264 + packetizationMode: 1) so it needs TWO different preferredPayloadTypes for them, rather than a single one.

@ibc

This comment has been minimized.

Contributor

ibc commented Jun 22, 2016

To be clear: when Firefox generates an SDP with H264 it has two H264 entries, with different payload types and different packetization-mode. Those are two different codecs so, why should the ORTC RtpSender.getCapabilities('video') provide a single H264 entry with an array of supported packetizationMode values and a single preferredPayloadtype?

@robin-raymond robin-raymond added the 1.2 label Jul 13, 2016

@aboba aboba self-assigned this Jan 11, 2017

@aboba aboba added 1.1 and removed 1.2 labels Jan 11, 2017

@aboba

This comment has been minimized.

Contributor

aboba commented Jan 11, 2017

@ibc The only scenario that comes to mind in which a browser may want to call rtpSender.send() with both codec_A (H264 + packetizationMode: 0) and codec_B (H264 + packetizationMode: 1) would be a conference with a legacy system (supporting only packetization-mode 0) as well as WebRTC browser clients (supporting packetization-mode 1, which is mandatory-to-implement). To accommodate both, the sender simulcasts both modes 0 and 1, with an SFU in-between to decide which stream to send to a given client.

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.

@robin-raymond

This comment has been minimized.

Contributor

robin-raymond commented 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.

@aboba

This comment has been minimized.

Contributor

aboba commented Mar 15, 2017

I believe this is addressed by PR #634

@aboba aboba closed this Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment