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."
> It's almost like this has been on Intel's CPUs for years...
Oh really?
So what build of ffmpeg on Linux supports this?
Having some weaker-than-everyone-elses GPU feature and actually having libre support for that feature are two entirely different things.
A Pirate and a Puritan look the same on a balance sheet.
Unless the binary mentioned is different from the various others in the directory, it's firmware that the driver needs to load onto the card on startup (which has been the case for Radeons for some time now) rather than a binary driver component that runs on within the host OS.
Distribution will be a hassle, as always; but it's not architecturally much different from just adding a chunk of flash to the card and storing the firmware there instead.
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.
FFmpeg (upstream SVN tree >= 2010/01/18 / version 0.6.x and onwards)
for reference: http://www.freedesktop.org/wik...
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
It is still a step backward, a last ditch attempt to rescue the patent encumbered CODEC before it becomes extinct. They should let it die, for the good of progress. Who wants a CODEC backed by a group that sued a mom for publishing a birthday video online over patent licensing?
Help stamp out iliturcy.
That's interesting. For anyone who, like me, wasn't familiar with Quick Sync, it seems to be a dedicated video codec chip on the CPU. In testing, it was much faster than CPU or even GPU encoding, but at lower picture quality per megabyte.
Encoding was added to the VAAPI interface, but was never supported by Intel hardware. There's not much sense implementing a protocol when there's no hardware to interface with. You may be looking for the Intel Media SDK, which wasn't made publicly available until the middle of last year.
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.
Encoding was added to the VAAPI interface, but was never supported by Intel hardware. There's not much sense implementing a protocol when there's no hardware to interface with. You may be looking for the Intel Media SDK [intel.com], which wasn't made publicly available until the middle of last year.
Intel says otherwise: Hardware encoding is supported with Intel HD 2000 and newer (Sandy Bridge)
Well, there's spam egg sausage and spam, that's not got much spam in it.