Closed
Bug 1081230
Opened 10 years ago
Closed 9 years ago
Poor audio/video latency/quality on same WiFi network
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: pdol, Unassigned)
Details
Attachments
(1 file)
1.16 MB,
video/quicktime
|
Details |
Firefox OS Version: 2.0.0.0-prerelease Build ID: 20141010000201 Firefox Desktop Version: 33.0 STR: - Connect FxOS device and desktop to same personal WiFi router - Launch Hello - Select a Contact (who doesn't have Hello) to dial - When person is unavailable, email them the URL - Recipient of the link (on desktop) launches the URL and initiates a call - After successfully connecting, observe video/audio stream Expected Results: Minor audio/video latency, understandable audio Observed Results: Significant latency and choppy audio
Reporter | ||
Updated•10 years ago
|
Summary: Audio and video mute buttons are confusing due to strikethrough icons → Poor audio/video latency/quality on same WiFi network
Please provide the following information: * Detailed information about the Firefox OS device you are using (model, ril, kernel, etc) * Whether this bug reproduces with Firefox 34 as the recipient * Whether this bug reproduces with Firefox 35 as the recipient * Whether this bug reproduces with Chrome as the recipient * Whether this bug only reproduces if Firefox OS is the host
Flags: needinfo?(pdolanjski)
Randell, I suspect you may need logs to debug this further. Can you please advise Peter how to get you the information you need?
Flags: needinfo?(rjesup)
Comment 3•10 years ago
|
||
Moving to Core / WebRTC as this is likely a WebRTC issue in the first instance (or it could be Firefox OS / Gaia:Loop).
Component: General → WebRTC: Audio/Video
Product: Loop → Core
QA Contact: anthony.s.hughes
Comment 4•10 years ago
|
||
This is done using the JB build which is not our target for performance optimization.
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #1) > Please provide the following information: > * Detailed information about the Firefox OS device you are using (model, > ril, kernel, etc) I updated to the KK build and the result is still similar. I'm using a Flame on 2.0 nightly user build (Build ID 20141016000201). It is using the 180 base image. > * Whether this bug reproduces with Firefox 34 as the recipient Yes, I used 34 for the test. > * Whether this bug reproduces with Firefox 35 as the recipient I'll try this shortly. > * Whether this bug reproduces with Chrome as the recipient Chrome 38.0.2 fails to connect to the FxOS device, giving "Call failed". > * Whether this bug only reproduces if Firefox OS is the host I haven't tried this yet.
Flags: needinfo?(pdolanjski)
Reporter | ||
Comment 6•10 years ago
|
||
Hmmm... I'm not able to connect anymore using 34, 35, 36 or Chrome, so it looks like there is another issue that I'm having.
Comment 7•10 years ago
|
||
You should really be using the 184 (or later) base image; it has much improved H.264 codec support in the DSP code. Also, current Nightly Mozilla Flame builds (user or pvt) and the original 180/184 base builds are not built (to my knowledge) with H.264 enabled, and are not built with support for hardware AEC and noise suppression (which is a build-time pref along with kernel changes); both of which are part of QC's base repo. Both of these make a significant difference in the load on the Flame in a call. Shell - do you know when base builds with H.264 and HW AEC enabled will be available for the flame?
Flags: needinfo?(rjesup) → needinfo?(sescalante)
I just received an email from B2G QA that the latest supported base image is v188 as of today. Probably best to try that image.
Comment 9•9 years ago
|
||
answered out of bug band via email - and let this needinfo sit until was obsolete. sorry.
Flags: needinfo?(sescalante)
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•