-
Notifications
You must be signed in to change notification settings - Fork 172
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
Support track level stereo and red setting #470
Conversation
🦋 Changeset detectedLatest commit: bdeff9c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
|
||
media.fmtp.some((fmtp): boolean => { | ||
if (fmtp.payload === opusPayload) { | ||
if (fmtp.config.includes('sprop-stereo=1')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does server
have to send this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it should have it if sending a stereo track
publishOptions.red = false; | ||
} | ||
if (publishOptions.dtx !== true) { | ||
publishOptions.dtx = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This and above is already checking for not true and setting to false. Should the check be if set to true, override it with false when stereo
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the red and dtx can be left to undefined, means use default
values. So this only disable them if dtx and red not enabled explicitly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this logic maybe live in publishTrack
instead of setTrackEnabled
?
If users choose to use the publishTrack
API directly, I guess they would have to handle all this by themselves otherwise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I agree this should be in publishTrack.
why do we need to set dtx or red to default false? It seems that we shouldn't change the default behavior of other unrelated params.
also, the logic would be easier to read with the ??
operator
publishOptions ??= {};
publishOptions.red ??= false
publishOptions.dtx ??= true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lukasIO sounds good, will move it there.
@davidzhao For stereo audio tracks, it will use high bitrates encoding (128kbps or higher) and most scenario is music, RED will cost more bandwidth and DTX might cause noise in special case or device. So disable them by default in stereo, user can enable them manually if need
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
solved by 9b8a0a4
src/room/PCTransport.ts
Outdated
if (stereoMids.includes(media.mid!)) { | ||
media.fmtp.some((fmtp): boolean => { | ||
if (fmtp.payload === opusPayload) { | ||
fmtp.config += ';stereo=1'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this check if config already has stereo=1
and add only if not there? i. e. will multiple pass through here keep adding stereo=1
? Guess it probably does not affect functionality, but the SDP could look strange.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test it will not be added repeatedly in chrome, but the check is safe for various browsers, will add it
publishOptions.red = false; | ||
} | ||
if (publishOptions.dtx !== true) { | ||
publishOptions.dtx = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I agree this should be in publishTrack.
why do we need to set dtx or red to default false? It seems that we shouldn't change the default behavior of other unrelated params.
also, the logic would be easier to read with the ??
operator
publishOptions ??= {};
publishOptions.red ??= false
publishOptions.dtx ??= true
// disable red and dtx for stereo track if not enabled explicitly | ||
let channelCount: ConstrainULong | undefined; | ||
if (options) { | ||
if ('channelCount' in options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when this is moved to publishTrack, determine the actual channelCount will be a challenge. we could take in a stereo?: boolean
parameter in publishOptions too, to give user control in case we cannot detect correctly.
In Safari, we could get channelCount from MediaStreamTrack.getSettings(). but Chrome doesn't seem to support that.. which means we may have to go look for it in the constraints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's also not fully fail proof but chrome should support at least getConstraints()
that would return the channel count in case it was manually set, which we could use as an indication of the user to publish stereo.
* Move all logic into and set explicit defaults * remove unnecessary null check * fix check * only log warning when red or dtx aren't set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good! remaining question about defaults
`Opus RED and DTX will be disabled for stereo tracks by default. Enable them explicitly to make it work.`, | ||
); | ||
} | ||
options.red ??= false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be great if we don't have to do this. It's confusing for the end user if what we indicate as defaults could change due to another parameter.
- red: I think the additional bw requirements is ok. If users doesn't want the redundancy, they could turn it off by themselves
- dtx: do you think this would cause issues when used in conjunction? can we test to validate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't had the chance to catch up on this whole thread, but I'm excited to test it out later this week!
Regarding red support, I will say that from my testing - high bitrate stereo + red (with DTX, noise canceling, echo canceling, etc. all turned off), audio sounds AMAZING. Using similar bitrates with opus by itself doesn't sound nearly as good. For my "quality audio mode" I plan to leave red enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the feedback @bekriebel ! that's wonderful to hear it made a significant difference in audio quality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is hard to reproduce, but a few users report noise with special music cases before, and we close DTX to fix it. At least, opus decoder will generate comfort noise
when received dtx packet, that is no needed and might harm to quality in music case. So I suggest disable dtx in stereo mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lg!
Co-authored-by: David Zhao <dz@livekit.io>
* Support track level stereo and red setting * check stereo is already exist * move options calc to publishTrack * prettier * Move all logic into `publishTrack` and set explicit defaults (livekit#474) * Move all logic into and set explicit defaults * remove unnecessary null check * fix check * only log warning when red or dtx aren't set * not disable red in stereo by default * Update src/room/participant/LocalParticipant.ts Co-authored-by: David Zhao <dz@livekit.io> Co-authored-by: lukasIO <mail@lukasseiler.de> Co-authored-by: David Zhao <dz@livekit.io>
* Support track level stereo and red setting * check stereo is already exist * move options calc to publishTrack * prettier * Move all logic into `publishTrack` and set explicit defaults (livekit#474) * Move all logic into and set explicit defaults * remove unnecessary null check * fix check * only log warning when red or dtx aren't set * not disable red in stereo by default * Update src/room/participant/LocalParticipant.ts Co-authored-by: David Zhao <dz@livekit.io> Co-authored-by: lukasIO <mail@lukasseiler.de> Co-authored-by: David Zhao <dz@livekit.io>
* Support track level stereo and red setting * check stereo is already exist * move options calc to publishTrack * prettier * Move all logic into `publishTrack` and set explicit defaults (livekit#474) * Move all logic into and set explicit defaults * remove unnecessary null check * fix check * only log warning when red or dtx aren't set * not disable red in stereo by default * Update src/room/participant/LocalParticipant.ts Co-authored-by: David Zhao <dz@livekit.io> Co-authored-by: lukasIO <mail@lukasseiler.de> Co-authored-by: David Zhao <dz@livekit.io>
No description provided.