Add backup codec policy to AddTrackRequest #947
Conversation
🦋 Changeset detectedLatest commit: cdf824f The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR 💥 An error occurred when fetching the changed packages and changesets in this PR |
| // default behavior, regress to backup codec and all subscribers will receive the backup codec | ||
| REGRESSION = 0; | ||
| // encoding/send the primary and backup codec simultaneously | ||
| SIMULCAST = 1; |
There was a problem hiding this comment.
should we keep the current behaviour as default? There are a few users probably used to this. Wondering if the default experience changes, if there are any ill effects.
Also, does the default behaviour change have impact on roll out? Would there be a flag to enable this?
There was a problem hiding this comment.
We had discussed the behavior and thought the customer would prefer the codec regression as it is suitable for most device/network that cost more subscriber traffic but save publisher bandwidth/power. So the customer could get codec regression without explicitly setting after sfu is released. Change the default behavior will not break the function of existed applications but just cost more traffic/money, I think it is acceptable. cc @davidzhao @lukasIO
There was a problem hiding this comment.
Would there be a flag to enable this?
Will have it to avoid break things.
There was a problem hiding this comment.
We had discussed the behavior and thought the customer would prefer the codec regression as it is suitable for most device/network that cost more subscriber traffic but save publisher bandwidth/power. So the customer could get codec regression without explicitly setting after sfu is released. Change the default behavior will not break the function of existed applications but just cost more traffic/money, I think it is acceptable. cc @davidzhao @lukasIO
Got it. Yeah, that sounds good @cnderrauber . I was mainly thinking about behaviour change and if applications would be affected by the change, i. e. the receivers able to receive advanced codec would now have maybe a couple of things happen?
- a brief disruption (am guessing this can be seamless with payload type switch, is that correct?)
- more downstream bandwidth use
There was a problem hiding this comment.
Agreed on codec regression being the default going forward though. I am convinced that is the right approach. Please ignore my original question on that.
I am just thinking about managing the transition phase.
There was a problem hiding this comment.
a brief disruption (am guessing this can be seamless with payload type switch, is that correct?)
this would of course be interesting to know when deciding on whether or not to change the current behaviour
There was a problem hiding this comment.
We had discussed the behavior and thought the customer would prefer the codec regression
I could imagine that especially some live streaming use cases would prefer SIMULCAST over REGRESSION.
There was a problem hiding this comment.
I could imagine that especially some live streaming use cases would prefer SIMULCAST over REGRESSION
yeah, we had focused on the livestreaming when implements the av1 support, that is why we have SIMULCAST first.
The publisher can set codec policy for how to primary codec are not support by subscribers, the default policy is regression to backup codec and all subscribers will receive the backup codec, this will make a change to current behavior (simulcast-codecs), the client can set it to
SIMULCASTexplicitly to get the same behavior in new version.