Firefox downgrades VP9 videos to VP8 when measured performance is not enough
On systems where H.264 is not available or no HWA, VP9 is preferred. But in Tor Browser 7.0 all youtube videos degraded to VP8.
Activity
Here it is https://bugzilla.mozilla.org/show_bug.cgi?id=1230265 And this is a fingerprinting vector for Tor Browser.
Trac:
Status: closed to reopened
Resolution: wontfix to N/A
Summary: Youtube downgrades VP9 videos to VP8 when can't find H.264 to Firefox downgrades VP9 videos to VP8 when measured performance is not enough
Keywords: N/A deleted, tbb-fingerprinting addedThe reality is https://bugzilla.mozilla.org/show_bug.cgi?id=1198715#c17 And "media.mediasource.webm.enabled is false by default on all platforms but linux", because of that bug is WONTFIX.
"We've found that some videos only play if you have VP9 enabled, which is why we enabled it unconditionally." from https://bugzilla.mozilla.org/show_bug.cgi?id=1266102, which disables "feature" on Android.
Trac:
Keywords: N/A deleted, tbb-easy addedReplying to gk:
Thanks for digging out the Mozilla bugs. Actually, this ticket is not
tbb-easyas it is not even clear how we should solve this problem. The same way as on Android. See patch from that ticket, we needIsVP9DecodeFast()be alwaystruefor all platforms, e.g. by-#ifdef MOZ_WIDGET_ANDROID +#ifdef 1and also
-#ifndef MOZ_WIDGET_ANDROID -#include "WebMSample.h" -#endif
Replying to cypherpunks:
Replying to gk:
Thanks for digging out the Mozilla bugs. Actually, this ticket is not
tbb-easyas it is not even clear how we should solve this problem. The same way as on Android. See patch from that ticket, we needIsVP9DecodeFast()be alwaystruefor all platforms, e.g. by {{{ -#ifdef MOZ_WIDGET_ANDROID +#ifdef 1 }}} and also {{{ -#ifndef MOZ_WIDGET_ANDROID -#include "WebMSample.h" -#endif }}} That's one option. However, note https://bugzilla.mozilla.org/show_bug.cgi?id=1286738 where this solution got basically reverted. (and we need to take mobile more and more into account as we plan to provide a Tor Browser on Mobile)-
Oh, and there might already have been a fingerprinting vector before this change got implemented, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1230265#c43
We're increasing the number of users for whom we're enabling VP9 from about 10% (people who don't have H.264) to 50% (people with fast enough machines). Well, then
+ return true;, of course. Unfortunately, settingmedia.mediasource.webm.enabledtotruedoesn't work. Dances with HWA detection are for Mozilla only, Tor Browser has all HW decoders disabled. Therefore, enabling VP9 unconditionally is the only way for it (this affects mobile, but reduces fingerprint). This also fixes the issue from your second comment.-
Replying to cypherpunks:
Set
media.benchmark.vp9.thresholdto0to fix this ticket without patching.Thanks for this suggestion. What are the implications of this proposed fix? (We'd need a patch for it as well)
Trac:
Keywords: tbb-easy deleted, N/A added
Status: needs_review to needs_information Replying to gk:
Replying to cypherpunks:
Set
media.benchmark.vp9.thresholdto0to fix this ticket without patching.Thanks for this suggestion. This is not only a suggestion, but the result of code analysis. What are the implications of this proposed fix? (We'd need a patch for it as well) All clients will get better experience and lower traffic, because TBB doesn't use
Use hardware acceleration when availableanyway. (Code analysis shows that you don't need a patch,-#include "WebMSample.h"is for cleanup only.)Trac:
Status: needs_information to new
A few notes. I reviewed mozilla-central and -esr52.
0: I agree, this is a hardware fingerprinting vector (albeit a small one, 1 bit of info). We should set the pref either very high (disabling VP9 for everyone) or to 0 (enabling it for everyone). Telemetry indicates more users fall below the 150 fps choice than above: https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-12-26&keys=__none__!none!none&max_channel_version=release%252F57&measure=VIDEO_VP9_BENCHMARK_FPS&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-12&table=0&trim=1&use_submission_date=0
1: The correct place to put prefs is browser/app/profile/000-tor-browser.js It's best to keep the prefs all in one place. (Also see #4 (closed))
2: Setting the pref does not enable vp9 on Android. That's probably fine, since all Androids will be hardcoded to false (no fingerprinting) and the point of disabling vp9 there is because it's not fast enough for phones. (True for -central and esr)
3: Setting the pref doesn't enable it on Macs. Same problem, except Macs are hardcoded false because it spins up the fan and annoys people. (Only true for central) Maybe this #ifdef should be backported to esr52 for TB? If it is I think it should be a separate commit/patch to make rebasing easier (on rebase we can just drop the individual patch entirely.)
4: The benchmark is skipped correctly when the pref is set manually. However, setting the pref in all.js means the pref won't have a user value, and the benchmark will be run. That's bad, so that's two reasons it should be in 000-tor-browser.js
5: I assume, but never verified, that prefs set in 000-tor-browser.js are considered to 'have a user value'.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1428351 for upstream.
Thanks for this work, I think once 1 is fixed, we should apply it. gk - do you want to backport the Mac hardcode in 3?