[Meta][User Story] Video Peer Connection calls (WebRTC P2P)

RESOLVED FIXED

Status

Firefox OS
General
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: ITsay, Assigned: drno)

Tracking

(Blocks: 1 bug, {meta})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ucid:WebRTC10, 1.4, ft:webrtc][NPOTB])

(Reporter)

Description

4 years ago
This is the user story meta bug for webRTC

Video calls between Firefox OS phones or between Firefox OS & other Firefox products
(Reporter)

Updated

4 years ago
Blocks: 922527
blocking-b2g: --- → 1.3?
Whiteboard: [ucid:WebRTC10, ft:media-recording, 1.3:p2][NPOTB]
(Reporter)

Updated

4 years ago
Keywords: meta
(Reporter)

Updated

4 years ago
blocking-b2g: 1.3? → ---
Depends on: 890419
Moved out of scope for 1.3, so pulling from tracker bug.
No longer blocks: 922527

Comment 2

4 years ago
Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]
Whiteboard: [ucid:WebRTC10, ft:media-recording, 1.3:p2][NPOTB] → [ucid:WebRTC10, 1.3:p2, ft:media-recording][NPOTB]
Whiteboard: [ucid:WebRTC10, 1.3:p2, ft:media-recording][NPOTB] → [ucid:WebRTC10, 1.3:p2, ft:multimedia-platform][NPOTB]
(Reporter)

Updated

4 years ago
Blocks: 947853
Whiteboard: [ucid:WebRTC10, 1.3:p2, ft:multimedia-platform][NPOTB] → [ucid:WebRTC10, 1.4:p2, ft:webrtc][NPOTB]

Updated

4 years ago
Depends on: 923361
drno indicated offline that he'll be handling the testing of this feature, so setting the flag on him.
Flags: in-moztrap?(drno)
(Reporter)

Comment 4

4 years ago
Hi Maire,

May I assign this bug to you temporarily for the follow up on the dependency of engineering work needed for the FC of this feature? Per our last discussion, Video call is under testing and we should be able to scope out how much work (or how many bugs) to do after the test. I need the help to link the engineering work to this meta bug for the tracking. Thank you!
Flags: needinfo?(mreavy)
Whiteboard: [ucid:WebRTC10, 1.4:p2, ft:webrtc][NPOTB] → [ucid:WebRTC10, 1.4, ft:webrtc][NPOTB]
Moving to 1.5 - we're going to be preffing this off for 1.4, as this doesn't fall under QC's & DSDS feature lists & isn't at FC quality yet. Initial testing showed significant performance problems under the reference device on a reliable wifi network, so we've got a bunch of work to do before we hit a FC quality bar. There was also evidence of video P2P calls consuming too much CPU on low end devices (e.g. Leo) to the point where touch interactions were lost intermittently.
Blocks: 974821
No longer blocks: 947853
Nils -- can you take the lead on determining the dependencies for this feature?  

All the targeted code to support this has landed, but we want to track how well this works on the target hardware (the Flame).  In particular, we want to capture any blocking performance and stability issues.  

Please use this bug to capture any issues (as dependencies) that may block this feature.  Thanks!
Assignee: nobody → drno
No longer depends on: 890419
Flags: needinfo?(mreavy)
I can already give input on this from the testing we did during MWC with Sandip. We're definitely not at a FC quality bar yet. After multiple attempts using Haxxor's wifi network in Mountain View trying to a video P2P call between two FxOS devices & FxOS device <--> FxAndroid, the FxOS device consistently ran into trouble being able to show consistent video frames for more than 5 seconds. You would usually get 5 seconds of video frames, a frozen video frame for a while, then another few seconds of video frames, and repeat. The audio latency was quite bad as well - Sandip & I constantly saw the audio falling behind in the video call very quickly, which made the call unusable.

We need to profile sample calls here and nail down why the performance is extremely bad.

Note - while the Flame is the target reference hardware for 1.4, we do need to make sure that other lower end hardware doesn't get into a bad state if P2P ends up being used. A different problem that was seen during testing was that if I tried to a P2P call with low end hardware (e.g. Leo) & tried to end the call, I'd end up losing the ability to use touch input on the device for up to 10 - 20 seconds. This problem is a certification blocker for release, as we can never end up in a state where touch input is lost due to using a phone feature.

Unless something changes within the next two weeks to drastically change the performance of video calls here, then I'd think this needs to wait until 1.5. We've got a high quality bar we must hit at FC per QC's requirements, which I don't think video P2P calls currently hit.

Comment 8

4 years ago
1. Which devices were you using?
2. Have you tried shrinking the video size?
(In reply to Eric Rescorla (:ekr) from comment #8)
> 1. Which devices were you using?

* Flame --> Flame
* Flame --> Galaxy S4 and vice versa

> 2. Have you tried shrinking the video size?

Nope - how would I do that?
(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Eric Rescorla (:ekr) from comment #8)
> > 1. Which devices were you using?
> 
> * Flame --> Flame
> * Flame --> Galaxy S4 and vice versa
> 
> > 2. Have you tried shrinking the video size?
> 
> Nope - how would I do that?

Edit all.js to reset the video size parameters to 320x240 and
rebuild
(In reply to Eric Rescorla (:ekr) from comment #10)
> (In reply to Jason Smith [:jsmith] from comment #9)
> > (In reply to Eric Rescorla (:ekr) from comment #8)
> > > 1. Which devices were you using?
> > 
> > * Flame --> Flame
> > * Flame --> Galaxy S4 and vice versa
> > 
> > > 2. Have you tried shrinking the video size?
> > 
> > Nope - how would I do that?
> 
> Edit all.js to reset the video size parameters to 320x240 and
> rebuild

Okay - I'll look at this in a bit. I'm assuming you mean these prefs:

* media.navigator.video.default_width
* media.navigator.video.default_height
So setting the default media.navigator.video.default_width & media.navigator.video.default_height to 320x240 reduces audio & video latency significantly. I managed to maintain an effective video & audio conversation for multiple minutes with that setting. I'll file a bug to change the prefs.

Updated

4 years ago
Depends on: 979726
(Reporter)

Comment 13

4 years ago
Hi Jason,

Is the video P2P pref-off in v1.4 already? Want to give some update about this feature status in v1.4. Thanks you.
Flags: needinfo?(jsmith)
(In reply to Ivan Tsay (:ITsay) from comment #13)
> Hi Jason,
> 
> Is the video P2P pref-off in v1.4 already? Want to give some update about
> this feature status in v1.4. Thanks you.

Nope - it's currently preffed on to my understanding.

http://hg.mozilla.org/mozilla-central/file/8122ffa9e1aa/modules/libpref/src/init/all.js#l236
Flags: needinfo?(jsmith)
(Reporter)

Comment 15

4 years ago
This is already preff on in v1.4. Close the user story.
Blocks: 947853
No longer blocks: 974821
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Flags: in-moztrap?(drno)
You need to log in before you can comment on or make changes to this bug.