This is the user story meta bug for webRTC Video calls between Firefox OS phones or between Firefox OS & other Firefox products

Moved out of scope for 1.3, so pulling from tracker bug.

Update whiteboard tag to follow format [ucid:{id}, {release}:p{1,2}, ft:{team-id}]

drno indicated offline that he'll be handling the testing of this feature, so setting the flag on him.

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!

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.

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!

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.

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.

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.

(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

This is already preff on in v1.4. Close the user story.