1335226 - Low quality video sent from Firefox

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Audio/Video, defect)

Description

[webrtcguy]

Attachment: screenshot showing the quality

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.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

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!

Comment 2

[Firefox Bug Husbandry Bot]

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.