3 ms·
> Bestsnip Animation Studio relies on the Webm VP9 video codec. Please use chrome or a chromium based browser to view this website. how is vp9 a problem? it's
by lousken 6y ago
> Bestsnip Animation Studio relies on the Webm VP9 video codec. Please use chrome or a chromium based browser to view this website.
how is vp9 a problem? it's been working for years in firefox
- pbhjpbhj 6y agoReportedly it doesn't work anymore: https://stackoverflow.com/questions/64273530/webm-vp9-support-in-firefox https://stackoverflow.com/questions/64273530/webm-vp9-suppor... . But MDN says it only works on Firefox with hardware support: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs https://developer.mozilla.org/en-US/docs/Web/Media/Formats/V... . Caniuse suggests https://caniuse.com/?search=vp9 https://caniuse.com/?search=vp9 it's fine on FF and works on Safari if you install the VP9 codec at OS level.
- chrismorgan 6y agoA couple of errors in your comment: 1. That Stack Overflow question is about MediaRecorder, which is encoding. It’s quite reasonable for a browser to support decoding (playing) a format but not encoding in that format. 2. That MDN page says nothing at all about the VP9/Firefox/hardware support combination—in fact it essentially says hardware support isn’t needed (“VP9 is widely supported by browsers, and hardware implementations of the codec are fairly common”). The other point it talks of with hardware support is saying that Media Source Extensions is only available for VP9 if no H.264 hardware decoder is available (which seems at first blush a curious restriction to make).
- pbhjpbhj 6y agoThanks. Wrt MDN, it may have been a misunderstanding. One para says it's preferable to use VP9 over VP8, the next is: > "3] Firefox only supports VP8 in MSE when no H.264 hardware decoder is available." // Which I took to mean, if there is a hardware decoder then it would support the better scheme, VP9. But I realise it's ambiguous. It also notes WebRTC requires support of VP8, so the interpretation It would be weird of availability of a hardware decoder meant that support for VPx was then completely lacking, when it could be provided when there was no such decoder. But clearly I only skimmed the sources, so if you're asserting that's true...?
- chrismorgan 6y agoNo, it’s definitely saying “if there is a H.264 hardware encoder available, MSE does not support VP8/VP9; but if there isn’t, then VP8/VP9 support under MSE is enabled”. There is no ambiguity in the wording. It’s a curious restriction, but I suspect it’s to do with the use cases for MSE and perhaps some inferiorities of VP8 and VP9 codecs for the MSE use cases, though I’m not sure. Adaptive bitrate streaming is caring a bit more about the trade-offs in network, CPU and whatnot, so preferring a codec with hardware support is perhaps reasonable—though I do wonder why it wouldn’t still have VP8 if it had a hardware decoder. I certainly don’t know the details of all this, but the wording on MDN is very clear. Remember also that WebRTC requiring VP8 doesn’t imply that anything else in the browser support VP8. Safari 11, for example, supports WebRTC but doesn’t support WebM or indeed VP8 anywhere else. Only Safari 14 starts to support WebM, and there only from Big Sur on.