PipeWire camera: use exact stream parameters specified by requested capability
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox132 | --- | fixed |
People
(Reporter: jgrulich, Assigned: jgrulich)
Details
Attachments
(1 file)
We currently specify stream parameters to be a range for both frame rate and resolution, where preferred value is specified. The preferred value
doesn't seem to be taken into account and we end up accepting any resolution from 1x1 to MAX_INTxMAX_INT. In case the other side tries to first match with lower resolution than requested, we will happily match it and start streaming low quality video. We should instead request the exact stream parameters as specified by requested capability. This capability always come from what has been originally reported as supported so it shouldn't happen we don't find a matching stream. This also applies to requested video format. We previously requested mjpg for streams with resolution higher than 640x480, but it doesn't necessarily mean the camera supports mjpg for the requested resolution. Again, refer to requested capability in this case as it should indicate what is supported and we know we can request exactly the same video format. It can happen that framerate is set to 0 as unspecified. In that case we should keep using a range as before, but with more sane values.
This has been fixed upstream and fix should be backported to Firefox.
|
Assignee | |
Updated•2 months ago
|
|
|
Assignee | |
Comment 1•2 months ago
|
||
We currently specify stream parameters to be a range for both framerate
and resolution, where preferred value is specified. The preferred value
doesn't seem to be taken into account and we end up accepting resolution
from 1x1 to MAX_INTxMAX_INT. In case the other side tries to first match
with lower resolution than requested, we will happily match it and start
streaming low quality video. We should instead request the exact stream
parameters as specified by requested capability. This capability always
come from what has been originally reported as supported so it shouldn't
happen we don't find a matching stream. This also applies to requested
video format. We previously requested mjpg for streams with resolution
higher than 640x480, but it doesn't necessarily mean the camera supports
mjpg for the requested resolution. Again, refer to requested capability
in this case as it should indicate what is supported and we know we can
request exactly the same video format. It can happen that framerate is
set to 0 as unspecified. In that case keep using a range as before, but
with more sane values.
This is a simple backport of an WebRTC upstream change.
Upstream commit: 9703f8474f156e08e4a96dc36253f1cdccd549e1
|
||
Comment 3•2 months ago
|
||
| bugherder | ||
Description
•