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

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Ivan Tsay (:ITsay)]

This is the user story meta bug for webRTC

Video calls between Firefox OS phones or between Firefox OS & other Firefox products

Comment 1

[Jason Smith [:jsmith]]

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

Comment 2

[Jean Gong :jgong]

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

Comment 3

[Jason Smith [:jsmith]]

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

Comment 4

[Ivan Tsay (:ITsay)]

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!

Comment 5

[Jason Smith [:jsmith]]

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.

Comment 6

[Maire Reavy [:mreavy]]

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!

Comment 7

[Jason Smith [:jsmith]]

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

[Eric Rescorla (:ekr)]

1. Which devices were you using?
2. Have you tried shrinking the video size?

Comment 9

[Jason Smith [:jsmith]]

(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?

Comment 10

[Eric Rescorla (:ekr)]

(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

Comment 11

[Jason Smith [:jsmith]]

(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

Comment 12

[Jason Smith [:jsmith]]

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.

Comment 13

[Ivan Tsay (:ITsay)]

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.

Comment 14

[Jason Smith [: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

Comment 15

[Ivan Tsay (:ITsay)]

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