Slashdot Mirror
AMD Open-Sources Video Encode Engine
An anonymous reader writes "AMD's latest feature added to their open-source Radeon DRM graphics driver is VCE video encoding via a large code drop that happened this morning. A patched kernel and Mesa will now allow the Radeon driver with their latest-generation hardware to provide low-latency H.264 video encoding on the GPU rather than CPU. The support is still being tuned and it only supports the VCE2 engine but the patches can be found on the mailing list until they land in the trunk in the coming months."
You said Intel CPU. Did you mean Intel GPU?
GPU encoding is about four times as fast as CPU. Of course that depends on which GPU is being compared to which CPU.
While I applaud AMD for their initiative there have been tests that show a drop in quality of GPU encoded H264 vs a CPU/software solution.
For details check out: http://www.behardware.com/articles/828-27/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html and http://www.tomshardware.com/reviews/video-transcoding-amd-app-nvidia-cuda-intel-quicksync,2839-13.html
I think, therefore you are.
Video decoder verification was the most tedious task I have ever been assigned. Just sayin.
From the mailing list, it appears you still need to link this all to a closed source binary...
No, it's firmware/microcode. The driver sends it to the GPU at boot as a blob, it lives inside the card hidden from everything. The alternative would be to have an EEPROM and a firmware flashing utility, it'd still be there and closed source but it wouldn't be in the driver. It's not really part of the programming model, it's hardware initialization/configuration/tweaks to make the it work correctly according to the model.
Live today, because you never know what tomorrow brings
That's not what he's saying and you know it. He's staying on the topic of this article which is Intel has provided open source h.264 encoding (VAAPI) for years while AMD is now releasing code. You could do a little research. As for ffmpeg, it doesn't support VAAPI but that is a choice of the ffmpeg developers not to include it; however, through the external libx264 library, you can get ffmpeg to encode h.264. This has nothing to do with Intel as they released the code. That's like complaining that it's the Khronos Group's fault if PowerVR decided not to support OpenCL on their new GPUs.
Well, there's spam egg sausage and spam, that's not got much spam in it.
They have decoding support, but at least as recently as Google Summer of Code 2013 they don't have hardware encoding support. That seems to be the fault of the ffmpeg project though, encoding was added to the VA API in June 2009. Lack of interest?
Live today, because you never know what tomorrow brings
I don't think it's quite nonsense. A motorcycle has lower latency than a truck (you can get there faster), but a truck has higher throughput (it can deliver 1000 boxes quicker). That's a useful distinction.
Especially Quick Sync can easily encode IN REAL TIME, so it's useful for DVRs, etc. (Think instant replay). An unassisted CPU will struggle with real time encoding. Being able to encode even multiple streams in real time is better than not being able to.