QA/WebRTC/OpenH264

From MozillaWiki
< QA‎ | WebRTC
Revision as of 06:10, 12 August 2014 by Nohlmeier (talk | contribs) (→‎OpenH264 Testing)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  • Owner: Nils Ohlmeier
  • Target: Fx33 (desktop only)

OpenH264 Feature

How the feature is suppose to work:

  • Approximately 1min after starting Fx33 it downloads the OpenH264 plugin in the background from this URL https://aus4.mozilla.org/update/3/GMP/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml
    • Before the download the OpenH264 plugin appears in the plugin section of about:addons with a "soon to be installed" warning
  • After the successful download the following user prefs get set:
    • media.gmp-manager.lastCheck, media.gmp-gmpopenh264.version, media.gmp-gmpopenh264.path, media.gmp-gmpopenh264.lastUpdate
  • The OpenH264 plugin appears as enabled in the plugin section of about:addons
  • The user can navigate to the plugins section on about:addons and manually set the plugin to disabled
  • The user can make WebRTC calls and Fx will offer H264 as secondary video codec after the default VP8

OpenH264 Testing

These high level areas need to be tested:

  • The download of the plugin
  • The activation of the plugin
  • The usage of the plugin and the Gecko Media Plugin (GMP) interface

Existing automated test cases:

  • test_peerConnection_basicH264Video.html uses the GMP fake plugin to make a call while using a codec from a GMP plugin

Assumption:

  • We assume that the H264 codec itself has been tested by Cisco, so that we don't have to test it in depth

Open questions/areas for testing/verification:

  • How to disable the download of the plugin and verify that setting works properly?
  • How to verify that not malicious code gets downloaded as the plugin?
  • How to verify the setting (?) which puts the plugin into disabled state after download?
  • How to verify that a broken XML on the download server is handled properly (needs definition of properly)?
  • How to verify that an outage of the download server is handled properly (needs definition of properly)?
  • How do we test and verify a new binary release of the plugin, before it gets release?
  • How to verify that the pre-compiled codec plugin binary works on all platforms?
  • How to verify that a disabled plugin results in no H264 offers in the SDP?
  • How to verify that disabling the plugin in the middle of a call is handled properly?
  • Do we need to verify cross-platform calling?
  • How do we test interoperability with mobile devices?
  • Is there a way to shorten the initial download delay of 60s to something less?
  • Can we do a manual installation from openh264.org instead?
  • Do we have any telemetry which tells us about the percent of failed installations in the field?
  • How do media.navigator.permission.disabled and media.getusermedia.screensharing.allowed_domains interact?

OpenH264 Bugs

Make sure these are verified fixed and have tests.

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1