-
Notifications
You must be signed in to change notification settings - Fork 508
Fix initial camera quality with Chromium #5932
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
Fix initial camera quality with Chromium #5932
Conversation
|
/backport to stable22 |
|
/backport to stable21 |
Due to a bug in Chromium it is not possible to increase the resolution of a track once it has been cloned. When the video was initially requested by Talk no resolution was specified, so Chromium returned a video track with a ~640x480 resolution, no matter the maximum resolution of the camera. As the track was immediately cloned, due to the bug, the maximum resolution of the track was limited to ~640x480. Now, if Chromium or a derived browser is used, the video is requested with a loose constraint for a high resolution, so if the camera does not have such resolution it will still return the highest resolution available without failing. If the track is then cloned then it will be possible to decrease and increase again the track resolution as desired instead of being locked to a maximum resolution of ~640x480. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
|
/backport to stable22.1 |
Signed-off-by: Joas Schilling <[email protected]>
f66c060 to
a81220a
Compare
PVince81
left a comment
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.
👍 code looks fine
Fixed it
Switching on Safari doesn't work, also before. |
|
The backport to stable21 failed. Please do this backport manually. |
Follow up to #5551
Due to a bug in Chromium it is not possible to increase the resolution of a track once it has been cloned.
When the video was initially requested by Talk no resolution was specified, so Chromium returned a video track with a ~640x480 resolution, no matter the maximum resolution of the camera. As the track was immediately cloned, due to the bug, the maximum resolution of the track was limited to ~640x480.
Now, if Chromium or a derived browser is used, the video is requested with a loose constraint for a high resolution, so if the camera does not have such resolution it will still return the highest resolution available without failing. If the track is then cloned then it will be possible to decrease and increase again the track resolution as desired instead of being locked to a maximum resolution of ~640x480.
Note that this only happens with real video devices; virtual video devices, like those created with v4l2loopback, do not have that issue.
You can verify all that with the following tests:
Please note that this time I could not test the pull request myself. Also please test with a Chromium derived browser, like Edge, to ensure that the user agent check works in that case too. And if you have two cameras try to switch between them during a call and check that the resolution worked as expected. Thanks :-)
How to test
getSenders()[0]instead):OCA.Talk.SimpleWebRTC.webrtc.peers[0].pc.getSenders()[1].track.getSettings()OCA.Talk.SimpleWebRTC.webrtc.peers[0].pc.getSenders()[1].track.applyConstraints({ width: { exact: 1280 } }).then(() => { console.log("Success") }).catch(error => { console.log(error) })Result with this pull request
The resolution of the video will be at least 720x540, and trying to increase it will succeed.
Result without this pull request
The resolution of the video will be 640x480, and trying to increase it will fail.