HEVC/AVC/VP9 decoders comparison

[Kurtnoise]

Hi all,

I'm looking for a recent comparison between the HEVC/AVC/VP8-VP9 decoders publicly available (free vs paying items might be great)...Is there a such thing that already exists ?

Thanks in advance.

[iwod]

decoders ?

[Guest]

decoders ? He stated that twice. What is the significance of your question?

[LoRd_MuldeR]

@Kurtnoise:

I think you might need to concertize what you are looking for. Are you looking for "plain" decoder libraries or "ready-to-use" products? In that latter case, those are usually made for a specific framework (e.g. DirectShow or GStreamer) or even for a specific application (like Avisynth plug-in's). So is there any specific framework or specific application you are focusing on? Last but not least: Is there a specific platform you are focusing on or are you looking for a cross-platform solution?

BTW: And what about "hardware accelerated" decoders? Or are you looking for software decoders only?

[Kurtnoise]

Yes, mainly software dshow decoders...but if there are some others x-platform libraries, it's fine.








/me testing libvpx vs libav VP9 decoding performance...

[LoRd_MuldeR]

As for AVC, I think LAVFilter (and thus libavcodec) is the way to go nowadays.

My last tests suggested that the libavcodec decoder is now on par or even faster than commercial alternatives, like DivX H.264 Decoder or CoreAVC. And in contrast to those, it's still under active development. Plus: It's free ;)

As for HEVC, it is supported by LAVFilter/libavcodec already. Not sure how complete/optimized libavcodec's HEVC decoder is right now, but it was working nicely for me to view some of the x265 samples...

(At the same time VLC Player, which also uses libavcodec, but maybe an older version, gave me horrible artifacts on those HEVC samples)

[nevcairiel]

libavcodec's HEVC decoder is complete, but not overly optimized yet. Its multi-threaded, but still has a lot of potential for improvements using SSE/AVX and the like, which is not implemented yet.

[tfouto]

libavcodec's HEVC decoder is complete, but not overly optimized yet. Its multi-threaded, but still has a lot of potential for improvements using SSE/AVX and the like, which is not implemented yet.

What about dxva in future? Will be possible to use dxva in the future to decode h265? Will it help significantly or not really?

Thanks

[nevcairiel]

What about dxva in future? Will be possible to use dxva in the future to decode h265? Will it help significantly or not really?

Microsoft already released a specification of the interface between software and the GPU.
However, it'll need new GPUs that actually support this. Hardware decoders are implemented in actual fixed-function hardware, which means you need a new GPU with new hardware.

How much it helps depends on how fast the decoders will be.
For actual playback, they would be smart to make them at least capable of UHD@60p, but its all just speculation and we'll have to see which performance target they go after.

[tfouto]

Microsoft already released a specification of the interface between software and the GPU.
However, it'll need new GPUs that actually support this. Hardware decoders are implemented in actual fixed-function hardware, which means you need a new GPU with new hardware.

How much it helps depends on how fast the decoders will be.
For actual playback, they would be smart to make them at least capable of UHD@60p, but its all just speculation and we'll have to see which performance target they go after.

So this means that actual GPU's wont be able to decode h265? There cant be anything that might be able to use dxva 2.0.

This new specification Microsoft made could evolve to something like dxva 3.0?

[nevcairiel]

So this means that actual GPU's wont be able to decode h265? There cant be anything that might be able to use dxva 2.0.

GPUs will be able to decode it, but no GPUs you can buy today.
You'll need a new one, once they support HEVC decoding.

[Ars92]

Broadwell and gt 8xx series better support those, thing is mobile CPUs of 2014 will be supporting HEVC. The snapdragon 800 on my note 3 doesn't seem to be able to support it yet, although it is said to support HEVC. But its understandable since this chip must have been made before the final spec was decided for HEVC.

Sent from my SM-N9005 using Tapatalk

[tfouto]

GPUs will be able to decode it, but no GPUs you can buy today.
You'll need a new one, once they support HEVC decoding.

Ok, thanks...

Any idea how much can be gained with optimization like SSE/AVX, etc? 5-10%

[nevcairiel]

Any idea how much can be gained with optimization like SSE/AVX, etc? 5-10%

Usually significantly more than that, but I don't want to make wild guesses on any numbers here.

[Beelzebubu]

/me testing libvpx vs libav VP9 decoding performance...

You know libav VP9 is mostly C and lagging behind FFmpeg's, right? So unless you care about specific forkiness, for this particular decoder you most likely want to measure libvpx vs FFmpeg-VP9.

The result (assuming x86-64, CPU bought in last 5 years) will probably be that ffvp9 beats libvpx-vp9 by about 20% (single-threaded), at least that's what I get in my current measurements. Multi-threaded gets complicated, because libvpx implements only tile-threading (or mostly useless loopfilter threading if tiling is disabled), whereas FFmpeg implements frame-mt. Which one scales better depends a lot on the selected encoder parameters (if parallelmode=0 and tile_colums>1, tile-mt scales better; else, frame-mt scales better).

[Kurtnoise]

This is what I got using the Performance Test tool from GraphStudioNext with my own compilation of the filters for a vp9 sample of 350 frames + default settings for each renderers...

I'm running on a Windows 7 Entreprise x64 platform - Core I3-2230M @2.20GHz -

http://uppix.net/9crSZ0.png

http://uppix.net/uFf9Tm.png

[nevcairiel]

If you're seeing speed of over 500 fps, then a test sequence of 350 frames is by far not long enough to give relevant data, as starting up the decoder can have a significant impact here.

[Kurtnoise]

Ok...then, I'll retry with a longer sample.

For you, how many frames could give us significant results in this case ?

[nevcairiel]

I usually prefer samples that take at least 30 seconds to decode for proper average numbers, so it can depend on speed a bit. Probably a bit less is also still OK, I would look for maybe 5000 frames or something like that.

[Beelzebubu]

What do these numbers even mean, is that fps or decode time? And why are they ~3x off between min/max for one of your samples (even 25% off is pretty massive, please do add N or stderr/ev)?

More importantly, "core i3" is a generic name, what architecture (haswell, sandybridge, etc.) is it based on (i.e. what optimizations does it have)? Can we assume the LAV-build you're using here is 64bit, and if so, what FFmpeg revision (+date) does it correspond to?

[Kurtnoise]

What do these numbers even mean, is that fps or decode time?
yes, fps...

And why are they ~3x off between min/max for one of your samples (even 25% off is pretty massive, please do add N or stderr/ev)?
dunno...note that the performance test from GraphStudioNext is basically a run of a sample where you are able to choose a decoder + a renderer. By default, the run consist of 10 passes. At the end, the decoding time + FPS are calculated (with the min, max and the average values).

More importantly, "core i3" is a generic name, what architecture (haswell, sandybridge, etc.) is it based on (i.e. what optimizations does it have)?
It's a sandybridge...

Can we assume the LAV-build you're using here is 64bit, and if so, what FFmpeg revision (+date) does it correspond to?
I'm using both...The first one uses the x64 filters and the second one the x86.

About the FFmpeg revision: it's quite hard to tell because LAV filters use the FFmpeg current branch + some patches.

[nevcairiel]

Should be fairly recent FFmpeg, if the LAV version you mentioned is correct, it should be FFmpeg from Feb 7th, f21d0be to be precise.
The short sample is probably not worth worrying about though, as the results seem much too similar between the two to be representable.

[Beelzebubu]

The biggest issue I have with these results is that the ffvp9 x86 vs. x64 results are so identical. You have to understand that most SIMD in ffvp9 is x64-only, so you would expect the x64-build to be significantly (in the realm of ~1.5x or so) faster than the x86-build.

[xooyoozoo]

libavcodec's HEVC decoder is complete, but not overly optimized yet. Its multi-threaded, but still has a lot of potential for improvements using SSE/AVX and the like, which is not implemented yet.

There's good progress on this front (https://github.com/OpenHEVC/FFmpeg/commits/hevc_optimized), but I don't know when they'll be ready to merge.

Compared to mainline, I'm getting more than double the per-thread performance.

[nevcairiel]

There's good progress on this front (https://github.com/OpenHEVC/FFmpeg/commits/hevc_optimized), but I don't know when they'll be ready to merge.

Compared to mainline, I'm getting more than double the per-thread performance.

Sadly they are using intrinsics and not bare-bone ASM, which will most likely not be accepted into upstream FFmpeg/Libav like this, without being converted to ASM first (which can be non-trivial)

While the OpenHEVC guys do good work, their final goal at this time sadly does not align with the upstream projects directly.

[Rafales]

Hope I'm sharing the news in the right section and not posted yet

The world’s fastest VP9 decoder: ffvp9
http://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/

[Procrastinating]

Given that VP9 does not have its own forum, This thread would be the most appropriate location. (http://forum.doom9.org/showthread.php?t=165839&page=21)