GPU Accelerated H.264 Encoder

[hust_xcl]

Originally Posted by schweinsz

I believe that the GPU for H.264 encoding matters only if the GPU can do interpolation, integer-pel and, mode decision, transform and quantization.
If you only offload the integer-pel ME and interpolation, it is less significant.

Sub-pel ME depend upon the interger -pel me. It will be the next step to do. Sometimes, Sub-pel ME costs more time than integer-pel ME. But, at first, we should offload interger me to gpu while mataining the encoding qulity.

[Sirber]

I came across this:

Parallelization of the x264 encoder using OpenCL
http://li5.ziti.uni-heidelberg.de/x264gpu/

[LoRd_MuldeR]

Can you please avoid including EXTREMELY large images directly in your post?

Thanks!

[kypec]

Maybe someone should inform those people that we're able to use colours to achieve better presentation on our screens. All that B&W looks like 20s' technology to me, not the third millennium we're actually in.

[deekey777]

The upcoming AMD HD7900 (SI) come with some new media processing instructions:
http://forum.beyond3d.com/showpost.p...postcount=1588
What do you think?

(And there will be an integrated videoencoder called VCE)

[CruNcher]

Nice i wonder what Nvidia will come up with im pretty sure they also worked on better Motion Estimation but AMD/ATI was first with Steady Video (Realtime Deshaking) and now enhances it 1 step further

[hajj_3]

here is some more info on AMD'S "Graphics Core Next" a.k.a GCN: http://www.anandtech.com/show/4455/a...ts-for-compute

[CruNcher]

Here is some new Information about the inner working of Quicksync and which parts are still related to the EU (Shaders) and how turbo boost influences this (frequency changes) http://software.intel.com/sites/land...d-applications
Its a very interesting read it also shows that their are still ways to improve the quality on the Driver side

Motion Estimation Track
The Motion Estimation Track is actually the kernel software which runs on the Execution Units (EUs) of the graphics unit. This kernel is executed while adaptively invoking the motion estimation acceleration hardware. The actual behavior depends on the TargetUsage set by the application. Here we can see 4 stages inside the Motion Estimation Track with MFX_TARGETUSAGE_BALANCED mode. The performance of this track depends on the usage parameter, but it is also affected by whether graphics Intel Turbo Boost Technology is on or off.

[BlackSand]

Originally Posted by Sirber

I came across this:

Parallelization of the x264 encoder using OpenCL
http://li5.ziti.uni-heidelberg.de/x264gpu/

I found this is rather old (2010) and still rather unknown work. But encoding speed gain may be impressive:
Readme from https://github.com/jnorthrup/gpu_x264:

this appears to be a splice from libx264.67.so which was not introduced to mainline x264 development.

with some amount of manual downloading and assembly i was able to encode 600 frames of big buck bunny per the original demo script at 151 fps on a 3.3 ghz stock i980x core i7 on linux 3.1pre with radeon 6970 @ 910mhz/300Ram-Mhz + AMD APP 2.5. (typically only 1x encoding by multicore cpu alone.)

credit given to original project authors http://li5.ziti.uni-heidelberg.de/x264gpu

James Northrup

Can someone make compiled encoder from this source? There are win32 project files in the "build" folder also. I think many people would be interested in testing this encoder.

May some of the x264 devs take a look into this project also? The only comments I've found is http://doom10.org/index.php?topic=571.0

[MasterNobody]

Originally Posted by BlackSand

May some of the x264 devs take a look into this project also? The only comments I've found is http://doom10.org/index.php?topic=571.0

There is nothing new here (copy of the same outdated sources with little bit changed demo.sh and configure). So that comments from the link are still valid.

[Filker]

Just found some opensource stuff to access VCE (AMD) in virtualdub (yes I still use it :P ) and a versatile screen capture util with VCE support. Gotta admit I never used AMD's utils built in the drivers (AMD Quickstream? Raptr? Gaming evolved? I dunno they just keep tossing out stuff with "user friendly" GUI's that won't get you anywhere) as they seem to be more game oriented.

OpenencodeVFW (based on AMD's openencode source):
https://github.com/jackun/openencodevfw

Open Broadcaster with VCE support:
https://obsproject.com/forum/threads...support.13996/

I only have VCE 1.0 equipment, so couldn't try out VCE 2.0 (kaveri, hawaii and low power am1 beema/mullins) which supports B-frames and up to 5.1 profile
It's fast (transcoding x264 720p at around 80 fps- perhaps bottlenecked by the decoder?), even on highest quality settings. But the bitrate/quality ratio isn't as good as x264.

My wishlist for VCE:
Higher quality even at the cost of speed decreases.
Dual graphics/X-fire support (use more than one dGPU and/or APU to encode/assist encoding the same stream).
hybrid GPU/x86 encoding: "software encoding" with more parts of h264 on the GPU, like OpenCL lookahead - maybe with HSA and the new H265 standard built around multi-core this will be easier to implement.