search

web-platform-tests / wpt

Test suites for Web platform specs — including WHATWG, W3C, and others
https://web-platform-tests.org/
Other
5k stars 3.1k forks source link

WebRTC: Firefox test doesn't load H.264 codec #10981

Open alvestrand opened 6 years ago

alvestrand commented 6 years ago

This test result:

https://wpt.fyi/webrtc/protocol/video-codecs.html

indicates that Firefox is being run in a mode that doesn't allow it to download the H.264 codec implementation that it usually uses. This makes Firefox fail a test that I think it should pass. Tagging @nils-ohlmeier for more knowledge.

foolip commented 6 years ago

The current results are from https://github.com/web-platform-tests/results-collection (@jugglinmike) but I asked to file the issue here because it presumably also affects the new Taskrunner setup. @jgraham, is this something you've worked around in Gecko testing infra?

foolip commented 6 years ago

The results are now at https://wpt.fyi/results/webrtc/protocol/video-codecs.https.html (and https://wpt.fyi/results/webrtc/protocol/video-codecs.https.html?label=experimental) but are unchanged. @jgraham, do you do anything special in Gecko CI to download the codecs before running tests? I can't spot anything in https://hg.mozilla.org/mozilla-central/archive/tip.zip/testing/profiles/ so I guess not?

mdittmer commented 6 years ago

Friendly ping. If this is priority:roadmap it should probably have an assignee. @foolip who would be a suitable owner for this?

foolip commented 6 years ago

Ping @nils-ohlmeier and @jan-ivar for thoughts on how to fix. This is a problem for Firefox that would probably be best dealt with by Mozilla. Since the priority: labels are used mostly (but not only) to track Google priorities, I'll mark this as backlog priority until there's someone to work on it.

nils-ohlmeier commented 6 years ago

By default Firefox starts with a user profile with no OpenH264 in it. For legal/licensing reasons we can't change that.

The two alternative are: 1) Wait for the download of OpenH264 to happen. Firefox waits by default I believe a couple of minutes of idle time (note: if the browser is actively used, e.g. with tests, the download won't happen as we don't want to affect what the user is actively doing right now). You can now these days trigger the check for missing add-ons in the preferences UI, but I don't know if that is accessible from JS. The problem is that AFAIK there is no JS method to verify that the download is complete and OpenH264 is ready to use. 2) If the OpenH264 add-on is already present in the user profile directory H264 can be used right away. So you either: a) Manually download the add-ons before starting Firefox and unpack it into the user profile directory b) Re-use an existing user profile which already downloaded the add-on.

I'm guessing that option 2) is easier for automation to accomplish.

agouaillard commented 6 years ago

Alexs-MacBook-Air:KITE cosmo$ grep -R OpenH264 *

third_party/firefox-h264-profiles/h264-mac/gmp-gmpopenh264/1.7.1/gmpopenh264.info:Description: GMP Plugin for OpenH264.

Binary file third_party/firefox-h264-profiles/h264-mac/gmp-gmpopenh264/1.7.1/libgmpopenh264.dylib matches

third_party/firefox-h264-profiles/h264-linux/gmp-gmpopenh264/1.7.1/gmpopenh264.info:Description: GMP Plugin for OpenH264.

Binary file third_party/firefox-h264-profiles/h264-linux/gmp-gmpopenh264/1.7.1/libgmpopenh264.so matches

third_party/firefox-h264-profiles/h264-windows/gmp-gmpopenh264/1.7.1/gmpopenh264.info:Description: GMP Plugin for OpenH264.

Binary file third_party/firefox-h264-profiles/h264-windows/gmp-gmpopenh264/1.7.1/gmpopenh264.dll matches

Alexs-MacBook-Air:KITE cosmo$ grep -R h264-windows *

KITE-Engine/src/main/java/org/webrtc/kite/WebDriverFactory.java: profile += "firefox-h264-profiles/h264-windows";

On Tue, Oct 23, 2018 at 6:53 AM Nils Ohlmeier notifications@github.com wrote:

By default Firefox starts with a user profile with no OpenH264 in it. For legal/licensing reasons we can't change that.

The two alternative are:

  1. Wait for the download of OpenH264 to happen. Firefox waits by default I believe a couple of minutes of idle time (note: if the browser is actively used, e.g. with tests, the download won't happen as we don't want to affect what the user is actively doing right now). You can now these days trigger the check for missing add-ons in the preferences UI, but I don't know if that is accessible from JS. The problem is that AFAIK there is no JS method to verify that the download is complete and OpenH264 is ready to use.
  2. If the OpenH264 add-on is already present in the user profile directory H264 can be used right away. So you either: a) Manually download the add-ons before starting Firefox and unpack it into the user profile directory b) Re-use an existing user profile which already downloaded the add-on.

I'm guessing that option 2) is easier for automation to accomplish.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/web-platform-tests/wpt/issues/10981#issuecomment-432091522, or mute the thread https://github.com/notifications/unsubscribe-auth/AAT1nvmwPI4YoYj0zgB2B1ZeM8kY9ZbBks5unqDWgaJpZM4T9gRe .

-- Alex. Gouaillard, PhD, PhD, MBA

President - CoSMo Software Consulting, Singapore

sg.linkedin.com/agouaillard

-

foolip commented 6 years ago

@nils-ohlmeier is there an URL or API for downloading those plugins, and will they always work with the latest Firefox Nightly? (IOW, will there be times when everything fails because of a transient mismatch in ABI, or something like that?)