979726 - Change the default preferences for media.navigator.video.default_width & media.navigator.video.default_height to 320x240 on Firefox OS

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Jason Smith [:jsmith]]

The testing on bug 923364 showed high evidence that switching the default width & default height to 320x240 significantly reduces video & audio latency on Firefox OS. With this setting, I was able to maintain a video & audio P2P conversation for multiple minutes with a low amount of latency.

Let's change the default prefs here for default width & height to 320x240 for Firefox OS.

Comment 1

[Andreas Gal :gal]

This should be dynamically configured.

Comment 2

[Jason Smith [:jsmith]]

(In reply to Andreas Gal :gal from comment #1)
> This should be dynamically configured.

Right - I think that's what bug 877954 is intending to fix.

Comment 3

[StevenLee[:slee]]

Attachment: patch

Change default camera capture size on B2G.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 8385906 [details] [diff] [review]
patch

Review of attachment 8385906 [details] [diff] [review]:
-----------------------------------------------------------------

r+ as a temporary solution

I'll note (as I noted elsewhere for the receive sizes (video.max_fs)) the default values for video capture may need to be a device-specific value.  

At this point, 320x240 seems a reasonable generic choice for PeerConnections on existing B2G hardware, though larger values may be fine for local uses of getUserMedia (and some devices (Unagi) may need less).  We should consider adding instead a separate max-peerconnection-encode-resolution pref (named something nicer) to limit the size we need to encode while allowing local use of gUM to be higher resolution.  This could be easily applied in VideoConduit.cpp

The dynamic load adaption should be better, especially if combined with appropriate constraints (agreed to in the W3) to let the app make tradeoffs between resolution and framerate (some apps may want high resolution at low frame rates, though that should not be the default).

Comment 5

[Andreas Gal :gal]

Randell, who is driving the dynamic stuff? That sounds really great. Lets make sure we land it.

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Andreas:

Maire and I are driving it as part of the media quality effort; this was ongoing before the current effort.  GCP has been doing the primary implementation on this with input from me.  We spent a lot of time working on this at the work week; gcp has majorly revised his patches and put them up for me to review (should be reviewing today after IETF meetings in London are over - I'm attending remotely to avoid chewing a lot of travel time/etc).

There are two types of adaptation: load adaptation, and bandwidth-driven adaptation.  In either case, the idea is to reduce resolution and/or frame rate to better fit in the available resources (and generally to prefer frame rate over resolution without input telling us otherwise).

Comment 7

[StevenLee[:slee]]

(In reply to Randell Jesup [:jesup] from comment #4)
> I'll note (as I noted elsewhere for the receive sizes (video.max_fs)) the
> default values for video capture may need to be a device-specific value.  
> 
> At this point, 320x240 seems a reasonable generic choice for PeerConnections
> on existing B2G hardware, though larger values may be fine for local uses of
> getUserMedia (and some devices (Unagi) may need less).  We should consider
> adding instead a separate max-peerconnection-encode-resolution pref (named
> something nicer) to limit the size we need to encode while allowing local
> use of gUM to be higher resolution.  This could be easily applied in
> VideoConduit.cpp
It will cause a resize overhead. For devices that have performance issues, we may need to evaluate whether the resize overhead is less than the reduction of encoding smaller video frames. 
> 
> The dynamic load adaption should be better, especially if combined with
> appropriate constraints (agreed to in the W3) to let the app make tradeoffs
> between resolution and framerate (some apps may want high resolution at low
> frame rates, though that should not be the default).
Agree.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

checkin request via IRC
https://hg.mozilla.org/integration/b2g-inbound/rev/6eb436a7b914

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6eb436a7b914