Closed
Bug 1335226
Opened 8 years ago
Closed 6 years ago
Low quality video sent from Firefox
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: forever.arihant, Unassigned, NeedInfo)
References
Details
(Whiteboard: [needinfo to reporter 2017/1/31])
Attachments
(1 file)
(deleted),
image/jpeg
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36
Steps to reproduce:
1. Login to messenger.com from FF running on windows - User A, machine 1.
2. On machine 2, use Fiddler to simulate UAString to chrome and login to messenger.com from Edge browser running latest windows insider preview 15019 (Webrtc 1.0 is enabled by default for this build) - User B
3. Initiate a call from User A to User B.
Actual results:
1. REMB is negotiated but abs-time header extension is not, so EDGE can't estimate bandwidth properly and is stuck at sending ~340k in REMB to FF. (bug tracking support for abs-timestamp: 1300665)
2. Ideally, 340k seems to be good enough to encode high motion content without blockiness. This seems to be a issue with the Firefox encoder's rate control.
Expected results:
1. For 340Kbps, video should have been seen with less blockiness, even when there is substantial motion. Chrome does a much better job of handling this scenario.
Updated•8 years ago
|
Comment 1•8 years ago
|
||
Why does Edge not do bandwidth estimation without those extensions? It shouldn't be needed, even if it (may) improve the quality of the estimation.
Also, can you record a screencast of the video in Firefox and Chrome for these cases (and verify with webrtc-internals and about:webrtc (or wireshark perhaps) that the video bitrates are the same?)
Thanks!
Flags: needinfo?(forever.arihant)
Whiteboard: [needinfo to reporter 2017/1/31]
Comment 2•6 years ago
|
||
2019-03-06
This bug is part of a group of bugs which have had an open needinfo for at least 12 weeks.
The request for information has not been answered, and we can't move forward on the bug so we are closing it.
If the defect is still present, please reopen this bug with an updated report.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•