User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20150926031337 Steps to reproduce: 1. Start 64-bit Firefox 42 beta or later on Windows. 2. Set media.mediasource.webm.enabled to true. 3. Restart. 4. Play youtube videos. Actual results: HTML5 player error occurs, then Flash plays the video instead. (32-bit Firefox doesn't affect this.) Expected results: HTML5 player is supposed to play the video, not Flash.
(In reply to sandthorn from comment #0) > 1. Start 64-bit Firefox 42 beta or later on Windows. > 2. Set media.mediasource.webm.enabled to true. If you're going to test experimental features that are disabled by default, you should do so in the latest Nightly. https://nightly.mozilla.org > (32-bit Firefox doesn't affect this.) Do you actually mean that 32-bit Firefox isn't affected, or do you really mean that there's no difference in 32-bit Firefox?
64-bit 42b, 43a2 and 44a1 Nightly are all affected, that is, an error occurs then Flash player comes along instead. 32-bit Firefox can play VP9 youtube videos fine in HTML5 player without any errors.
This can be fixed by set media.webm.intel_decoder.enabled to false
Taking this one ; the intel VP8 decoder is something that hasn't received any love for a while and apparently is broken as confirmed by this bug.
@Jean-Yves Avenard I guess VP8 is no longer being streamed on youtube anymore. And perhaps this is only an CPU specific issue. Only Haswell or newer Intel CPU support VP9 acceleration, of course, from modern drivers. New Intel IGP drivers add H.265, VP9 hardware decode support http://techreport.com/news/27677/new-intel-igp-drivers-add-h-265-vp9-hardware-decode-support Anyway, should this setting media.webm.intel_decoder.enabled be simply ignored when the hardware (and the driver) is not qualified rather than falling back to flash?
(In reply to sandthorn from comment #5) > Anyway, should this setting > media.webm.intel_decoder.enabled > be simply ignored when the hardware (and the driver) is not qualified rather > than falling back to flash? It should already be ignored if it's not a haswell or later CPU.
Actually marking it as duplicate, and this will now be fixed thanks to bug 1211339