A High Performance, OpenCL-Based VP9 Encoder

[log0]

Smells like BS to me. All they probably do is moving the parallelizable parts to OpenCL (intra prediction, motion search ....). Whch will give you < 50% speedup.

Related to this maybe? https://github.com/ittiamvpx/libvpx

[utack]

I don't think that VP9 is a target for an average consumer to save their home videos. It is used by google with bitrates more comparable to H.264 than H.265.

Googles vp9 encoder actually manages to destroy the best of H264 encoders

http://compression.ru/video/codec_comparison/hevc_2015/figures/chart_2.png

[carewolf]

How well a codec can be accelerated by shaders depends heavily on the codec and which parts are amenable to parallel processing. Switching between CPU and GPU for different parts of the decode pipeline really hurts. This is somewhat better with OpenCL compared to OpenGL. IIRC, newer codecs like VP9 are more amenable to acceleration using shaders than older codecs like H.264.

I am guessing it is mixing a lot of GPU and CPU, but with a shared memory architecture that is not that expensive, but could possibly be useless with a discrete model.

[liam]

Googles vp9 encoder actually manages to destroy the best of H264 encoders

http://compression.ru/video/codec_comparison/hevc_2015/figures/chart_2.png

FYI, a better tool:
https://arewecompressedyet.com/?r[]=x264-ntt-short-1b&r[]=x265_1.6_ntt-short-1&r[]=libvpx-vp9-1.4.0-ntt-short-1&s=ntt-short-1

That compares vp9, h264/5 using fastssim and with a wide range of video clips.

[Veerappan]

Smells like BS to me. All they probably do is moving the parallelizable parts to OpenCL (intra prediction, motion search ....). Whch will give you < 50% speedup.

Related to this maybe? https://github.com/ittiamvpx/libvpx

Thanks for the link. That repo definitely contains VP9 OpenCL code, although I haven't tested it to make sure it's complete. I'm poking at the api usage and kernels right now. Beyond the Mali support, it looks like they did some dev/testing on Intel HD graphics as well (not sure if it was in Linux/MacOS/Windows and using which driver).

[rabcor]

This might be pretty big for media streaming.

[Gusar]

Googles vp9 encoder actually manages to destroy the best of H264 encoders
http://compression.ru/video/codec_co...es/chart_2.png

Y-SSIM *in no way* correlates to visual quality. That graph doesn't tell you *anything* about how good the encoded videos actually look like. I did a test, three identical encodes except for the tuning - psnr, ssim, film: http://www.phoronix.com/forums/forum...426#post818426 <- as you can see there, the film tuning is the only one actually looking good, while having the lowest scores. Note that y-ssim is even worse as a comparison tool than the ssim I used in that test, as y-ssim completely ignores color (the y plane contains only brightness information).

So no, vp9 doesn't destroy anything. It only has psnr and ssim tuning, what it's lacking is a tuning that would actually make the video look good. The x264 devs stopped caring about ssim many, many years ago. Because of what my test there clearly demonstrates.


As for this OpenCL encoder, all GPU encoders until now have been terrible, no exceptions. That's why nowadays there are dedicated hardware encoders as part of the GPU (encoding does not happen on the shader cores of the GPU, but on this dedicated circuitry). These do better, but I still wouldn't archive my videos with them, as they can't reach a well tuned software encoder such as x264. This opencl vp9 encoder might be passable for two reasons: a) libvpx is quite crappy as an encoder, so another encoder can more easily reach it, compared to trying to reach x264 with a hardware encoder. And b) it's targeted at ARM, which have very low performance CPUs, compared to desktop CPUs.

[SystemCrasher]

Wait... wasn't OpenCL not suited enough for such tasks? Or maybe the FOSS developers who tried to develop the H264 OpenCL decoder weren't simply talented enough?

Hmm? There is OpenCL based encoding in x264 and it even appears to work on opensource AMD driver. WTF?

[SystemCrasher]

Googles vp9 encoder actually manages to destroy the best of H264 encoders
http://compression.ru/video/codec_co...es/chart_2.png

Actually, VP9 looks interesting. In its best modes it can do something like 1080P at 1Mbit/s (100Kbytes/s). Several times below of youtube's typical bit rate. And in most scenes it still going to be quite hard to spot artifacts. I've experimented on coding (uncompressed) Tears of Steel trailer and some few other uncompressed sequences, and really like how it performs. VP9 kicks the ass, allowing very nice bitrate/quality tradeoff. Especially in recent versions. Google did quite a good job tuning, tweaking and optimizing VP9.

Somehow, MPEG reference implementations both utter crap, come with insane licensing terms and fail to show why their standard rocks.

And on side note, VP9 artifacts aren't annoying/eye catching in most cases, especially on moving pictures. SSIM and somesuch do not measure quite many aspects related to this. There're some cases where it can be otherwise, but actually, x264 usually performs worse for me. And what is the point of x265, if I have to deal with MPEG LA and other MAFIAA? Youtube already uses VP9 and most browsers are ok with it for quite a while.

There is only one downside: encode can be quite slow using best quality settings . So idea to offload some parts to GPU looks interesting.

[darkbasic]

Hmm? There is OpenCL based encoding in x264 and it even appears to work on opensource AMD driver. WTF?

1) H.264 OpenCL encoder is almost useless, did you ever try it?
2) I was talking about DECODING.