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...
From the mailing list, it appears you still need to link this all to a closed source binary...
Now if only we actually had support for a codec that isn't patent-encumbered and actually included as part of standard releases?
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.
Years ago, ATI famously made multi-media versions of their graphics cards, designed for dual output, where the second output would likely be a TV set. Users needed, understandably, high-quality video-decode on the TV output, and this meant access to the video-decode hardware and the resize video filters. At first, ATI's drivers did exactly this, but then one day the new drivers REMOVED all hardware acceleration form the secondary output.
AMD lied about the situation- said it was a 'bug' and promised to put back the functionality. They never did (remember, I'm talking about then, not now). S, what happened?
Microsoft happened. Microsoft determined that ATI was encouraging dual simultaneous use of a Windows licensee. One child could be doing homework on the PC, while at the same time the PC could be playing a movie on the TV set for the rest of the family. Nothing illegal about this situation, but Microsoft didn't like it. So Microsoft told ATI to cripple their drivers- an order ATI most certainly did NOT have to follw, but ATI (AMD) always put their paying customers LAST over the interests of corporate requests.
Roll forward to a few years back. AMD refused to allow users to have general access to the hardware video decode path of ATI graphics hardware. So, if for instance you are doing video editing, you are forced to decode the video streams in hardware. AMD's excuse for this sickening refusal to allow people access to hardware features they paid for? The lobby groups for film and TV producers claimed that such restrictions would help fight 'piracy'. This despite the fact that AMD already supported the DRM protected path video decode, designed to prevent access to the raw frame data of DRM protected commercial video.
Intel and Nvidia BOTH allowed users of their hardware to access video decode functionality for editing and the like. AMD was the ONLY company to refuse access.
It is the EXACT same story with AMD's video encode hardware, AMD's JPG encode/decode hardware, and AMD's Trueaudio hardware. AMD is the WORST company in the world for respecting the rights of its paying customers. AMD managers love to wine and dine with suits form other companies, and treat these suits as the ONLY voice worth listening to. And these suits have every excuse in the world to request that AMD deny its paying customers open access to the hardware they own.
Today, AMD's biggest buzz is the Mantle API. Despite the fact that this API supports AMD GPU hardware that has been out for years, AMD has stated it has ZERO plans to open the API to the general programming community. At best, AMD has said it MAY consider providing an open SDK at the end of this year. And what does this mean in practice? That ONLY if unbearable commercial pressure falls on AMD (unfavourable market competition) will AMD provide its customers with low level access to their own hardware.
Who ever thought hardware H264 encoding matched the quality of a decent x264 encode? Exactly no-one.
People want access to hardware video encoding for various reasons- and quality is not one of them.
- because they've paid for the hardware, and should be able to access it
- because hardware encoding reduces the workload on the CPU
- because hardware encoding may be 'good enough' for many use cases
- because hardware encoding can be vastly faster on computers lacking the most expensive i7 Intel processors.
- because hardware encoding allows low latency streaming of game output video to remote wireless devices, allowing the AAA PC games to be played on Android gaming tablets (tablets with integrated physical joypad controls).
Again, no-one wants their Bluray rips to have been created on AMD (or Intel or Nvidia) hardware encode units. But we don't need you to point out this glaringly obvious fact.
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.
> it was much faster than CPU or even GPU encoding, but at lower picture quality per megabyte.
That is like saying that car A used much more fuel while driving much faster than car B. /dev/zero > videofile
Guess what, I have the fastest video encoder of all:
cat
Sure, the quality sucks, but you won't find any faster!
Yeah, great idea. If your goal is to create the slowest encoder ever. But then you could just use the reference encoder, it is already unusably slow, no need to go coding.
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.
If you read the ffmpeg mailing list they soundly fried the Intel hardware developers for implementing instructions that they felt were useless. They threw a bit of a hissy because Intel didn't ask them what they needed and instead surprised them with a bunch of functions they said weren't going to speed things up.
Rightly or wrongly that appears to be what happened. I researched this not too long after having gotten a Sandy CPU in hopes that I'd be able to speed up the BD encoding I was doing. No such luck! Decoding yes, encoding NOPE! Sadly video cards don't seem to offer the flexability that is desired either and tests have shown that software encoding has higher quality than that done by video cards I'd LOVE to see ffmpeg do something with this...