Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Safari still uses significantly less CPU while decoding video.


Safari does not support vp8 or vp9 when playing youtube, and youtube serves h264 instead. h264 is less efficient in terms of compression ratio (more to download for the same quality), but h264 is decoded in hardware on OSX, and VP8 or VP9 isn't, which explains what you see.

This is why, for example, Safari does not have 4k video on Youtube, while being perfectly capable of playing 4k videos in general.

Depending on the machine, VP9 can be decoded in hardware on Firefox on Windows, but chip support is limited.

All that said, we're working on our video playback performance as we speak, especially on OSX (because it was so bad a few release back), but also in general.


Thanks for the explanation.

I found this extension that forces FF to use H264 instead: https://addons.mozilla.org/en-US/firefox/addon/h264ify/

On my old MBP I'd rather consume more bandwidth than more more CPU.


Thanks for the link. On Firefox/Linux nvidia drivers, I don't see much difference in h264 vs VP9


We don't do hardware decoding on Linux for now, because we don't do hardware acceleration for graphics by default on Linux.

Web Render might allow doing it properly, since the rendering is not on the CPU anymore.


Also from the Q&A at the end:

> Safari’s compositor is entirely Core Animation based; Safari basically skips step 2.

(Step 2 is "the Firefox “compositor” assembles Gecko layers to produce the rendering of the window")


You think this affects video decoding?

Anyway, I imagine that's the price to pay for being crossplatform. You can't implement everything for every platform. Safari only has to work on macOS/iOS.


> You think this affects video decoding?

Speaking for Chrome's implementation, efficiently rendering video on macOS does require CALayer compositing, but it's not sufficient.

Only certain types of decoded frames can be efficiently scanned out (different from the types that can be used efficiently in OpenGL compositing). Actually entering the most efficient fullscreen video mode requires some magic. Matching macOS behavior exactly when a fallback to OpenGL compositing is required can be difficult (eg. colorspace bugs can result in flickering).

I have not looked at the new code in Firefox, but I would expect that not all of the benefit would be realized in a first release. In any case it's a huge undertaking to support a single platform; congrats to the team for making it happen!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: