Hacker News new | ask | show | jobs
by bitmapbrother 3967 days ago
VP9 being 9x slower than x264 is hard to believe. Do you have a citation?
2 comments

"VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. ... libvpx multithreading [encoding] performance is deplorable. It gains virtually nothing."[1]

1. https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastes... n.b. x264 comparisons were taken with `--preset veryslow` which understates x264's potential performance by an order of magnitude. From the same link: "it can be fast, and it can beat x264, but it can’t do both at the same time."

This is old. libvpx 1.4.0 is a lot faster now and has multithreading. On my i7-4900MQ laptop, I get about 3fps encoding 1080p content. Still very slow, but 24 minutes for a 3 minute clip, not days.
I can anecdotally agree with him. I ran a service that did a lot of media encoding and VP9 is very, very slow to encode.
Could that be due to lack of hardware support?
No, generally encoding is done in software. It's just because VP9 is a much more complex format with many more different coding possibilities to search. It also hasn't been around as long as x264 to be hyper-optimized.
There are probably some issues with missing SIMD, but no further hardware support would be helpful.

It's purely an implementation issue - you don't get software as good as x264 just by paying for it.

Comparing x264 to hardware-accelerated encoders (QuickSync, NVENC, VCE), the speed/quality/bitrate tradeoff is massively in favour of the cpu-only x264. So i think hardware encoding could help VP9, but it's not a magic bullet (unless your CPU is busy with other work simultaneously).