[tbb-dev] Media Codecs and the canPlayType/Media Capabilities API

[Georg Koppen]

Tom Ritter:
> On Wed, 6 Feb 2019 at 11:33, Tom Ritter <tom at ritter.vg> wrote:
>> I suppose step one is to make a fingerprinting test that identifies
>> what codecs you can handle...
> 
> I started work on this; but got some tribal knowledge from jya and others:
> https://mozilla.logbot.info/media/20190206#c15931239-c15932085

Thanks for getting this started, really appreciated! What's the story on
Android (given that we are not far away from shipping stable Tor Browser
bundles to mobile users)?

> Summarizing:
>  - Only AAC, h264, and vp9 may give different reports

I think it would still be good to verify that for other codecs and be it
just to catch possible regressions.

> - AAC Mac - always there
> - AAC Windows - May not be present on Windows N or KN
> - AAC Linux - Missing if ffmpeg is missing
> 
> - h264 Mac - always there. Almost always accelerated, except
> "hackintosh with nvidia cards and the mac pro 2013 trashcan"
> - h264 Windows - always there; but not hardware accelerated if your
> GPU card is blocklisted
> - h264 Linux - Missing if ffmpeg is missing or not compiled with h264
> support. never hardware accelerated.
> 
> - vp9 Mac - Always present
> - vp9 Windows - Always present, but may or may not be hardware
> accelerated. If not hardware accelerated, you can roughly benchmark
> the machine using different video size inputs and the resulting output
> of the smooth value
> - vp9 Linux - Always present
> 
> So by hardcoding a response for hardware acceleration and the smooth
> value; the only data we would leak would be information about your
> ffmpeg install (or lack thereof) on Linux; and on Windows whether
> you're missing the Media Framework (which is a good indicator of being
> a European user AIUI).

Yep. So, let's get started with that approach.

FWIW: I am not sure where we are with the Display Capabilities section
of the spec but §4.2 seems to show the way forward with respect to the
resist fingerprinting mode.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20190207/f7d307cd/attachment.sig>