Closed
Bug 1200768
Opened 10 years ago
Closed 1 year ago
WebrtcVideoConduit cannot cope with having more than one H264 recv codec
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
FIXED
138 Branch
| backlog | webrtc/webaudio+ |
People
(Reporter: bwc, Assigned: pehrsons)
References
Details
(Keywords: webcompat:platform-bug)
Attachments
(1 file)
Currently, we can only have one H264 recv codec on a given WebrtcVideoConduit. If there are multiple H264 codecs in an answer, the last one will be what is configured, which is of course not likely to be what is sent. This will need to be fixed before we are able to accept multiple codecs in an answer.
There are a handful of possible fixes, including:
1. Only use the first H264 recv codec (will probably squeak by in most cases, since the other end will probably not actually switch on us).
2. Fix this limitation by having multiple H264 decoders.
3. Only offer one H264 codec in the first place.
| Reporter | ||
Comment 1•10 years ago
|
||
What do you think about these options? I have option 1 implemented in my simulcast negotiation work, and it works ok. If this is not enough in the short-term, I'll need to modify the simulcast patch to not put multiple different codecs (per simulcast version) in answers, and only use one recv codec like before.
Flags: needinfo?(rjesup)
Updated•10 years ago
|
backlog: --- → webrtc/webaudio+
Rank: 17
Priority: -- → P1
Comment 2•10 years ago
|
||
Let's land option 1, and file a followup for option 2 at a lower priority.
Byron - are you good with this? Thanks.
Flags: needinfo?(rjesup) → needinfo?(docfaraday)
Updated•10 years ago
|
Assignee: nobody → docfaraday
| Reporter | ||
Comment 3•10 years ago
|
||
We've already landed option 1 in bug 1203246. We can leave this bug for option 2.
Flags: needinfo?(docfaraday)
Updated•10 years ago
|
Rank: 17 → 22
Priority: P1 → P2
Comment 4•8 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
| Reporter | ||
Updated•7 years ago
|
Assignee: docfaraday → nobody
Updated•3 years ago
|
Severity: normal → S3
| Assignee | ||
Updated•1 year ago
|
Assignee: nobody → apehrson
Status: NEW → ASSIGNED
| Assignee | ||
Comment 6•1 year ago
|
||
Here's a manual repro case: https://jsfiddle.net/pehrsons/h1x8ytj9/
| Assignee | ||
Comment 7•1 year ago
|
||
Comment 8•1 year ago
|
||
The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:
- Bug 1950834: S2
:pehrsons, could you consider increasing the severity of this bug to S2?
For more information, please visit BugBot documentation.
Flags: needinfo?(apehrson)
Updated•1 year ago
|
Keywords: webcompat:platform-bug
Comment 10•1 year ago
|
||
Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/41b771516141
Forward all receive codec payload types to libwebrtc. r=ng,jib
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/51159 for changes under testing/web-platform/tests
Comment 12•1 year ago
|
||
| bugherder | ||
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox138:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 138 Branch
Upstream PR merged by moz-wptsync-bot
Updated•11 months ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•