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

Yes x265 is not in the conversation for even top 5 HEVC encoders, regardless of presets. [1] It can be especially surprising because x264 is easily the best AVC encoder. For whatever reason (patents, lack of browser support etc) there just hasn't been as much engineering effort put into x265.

Now things like NVENC are even worse in terms of compression. Any GPU accelerated encoder trades compression efficiency for speed. Even x265 with the slowest presets will demolish any GPU encoder in terms of compression, including the MainConcept paid one when it's run in GPU-accelerated mode. This is unfortunately not explained in GUIs like Adobe tools. They just have a checkbox or dropdown to select GPU acceleration, but don't mention that it's not just acceleration - a different algorithm will be used that can't achieve the best compression.

GPU accelerated compression can still be very useful for scenarios where you need speed (e.g. have a deadline) or just don't care about quality (e.g. will publish it only on social media where it will be recompressed anyway). However when you have time to wait and want top quality, the slowest CPU-only code path will always win.

--

[1] One good public resource is the Moscow State University page http://www.compression.ru/video/codec_comparison/index_en.ht... -- They do regular comparisons of various codecs and some results are available for free. A bit in HTML form and more in some of the PDFs. Deeper insights are unfortunately paid.



Are there any CPU+GPU pipelines that improve the speed without decreasing quality to the level of current GPU-only algorithms?

Seems strange that we have so much compute power in GPU, but no algorithms to use it well for encodes


"GPU encoders" don't use the GPU themselves (shader cores), they use another tiny CPU attached to the GPU. GPGPU does not really help with compression much.




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

Search: