Poor audio/video latency/quality on same WiFi network

RESOLVED INCOMPLETE

Status

()

Core
WebRTC: Audio/Video
RESOLVED INCOMPLETE
4 years ago
3 years ago

People

(Reporter: pdol, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8503313 [details]
IMG_0104.MOV

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

4 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)
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

4 years ago
This is done using the JB build which is not our target for performance optimization.
(Reporter)

Comment 5

4 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

4 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.
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

3 years ago
answered out of bug band via email - and let this needinfo sit until was obsolete.  sorry.
Flags: needinfo?(sescalante)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.