Hardware accelerated encoding

B

bluefoot

New Member
Hi,

Since X.264 can now be accelerated using OPENCL, will you be looking to support this?

Since 90% of the streamers using this software will be on Sandy / Ivy Bridge (Haswell in future), using the on-die GPU (which various X.264 encoders are now using to accelerate the process via OPENCL) seems like a 'free' way to improve peformance considerably.

If support for this was added, I'd imagine that with a C985 to capture, and the on-die graphics (or a second graphics card) to encode, streaming would become almost 'free' in performance terms, which is obviously a good goal to work towards.

Thanks!
 
B

bluefoot

New Member
Feel free to merge this with the other thread ... for some reason no results were shown when I searched for OPENCL before posting this :/
 
R

R1CH

Forum Admin
Developer
There don't appear to be very big improvements from the OpenCL x264 build, the only improvements come from high end GPUs. The ability to use Intel Quick Sync for encoding however is certainly worth looking into.
 
F

Fred_

New Member
Everything but the CPU is pretty much pants for encoding. Haswell should help a bit, but that's because of the new instruction sets, not the igp.
 
B

bluefoot

New Member
QuickSync is a just a marketing name for using the IGP for GPGPU tasks. There's nothing special about it.

If performance is poor, then that's likely poor optimisation or coding in general. The x264 guys have stated that OPENCL implementation should improve performance significantly when using IGPs, for what ever they're used to accellerate ... the problem lies in rewriting x264 to take advantage of this ... so for the time-being they're doing the 'easy' bits, like Look-Ahead. Since, from my understanding, this is also one of the things that (x86) CPUs are poorest at, and poor at scheduling, it ought to be worth implementing as it may improve overall performance and reduce perceived input latency / stutter when streaming.

In future, I can imagine AMD slave cards (namely because their GPU architecture is better suited than NVIDIA's) or cheap ARM SoCs on PCI-e cards doing all the capture and most if not all of the encoding. Either solution ought to be far better value than the extremely over-priced C985, too.
 
T

Tak0r

Member
One thing to Consider is you can't use Quicksync if you use a discrete graphics adapter or to be more precice your Intel IGP has to be the primary one for this task. If you want to you have to use a Graphics virtualization like Virtu oder Virtu MVP.
 
Krazy

Krazy

Town drunk
That's only for certain chipsets, like the P67 as far as I'm aware. Other chipsets are able to use both without problems (or so I understood)
 
B

Bensam123

Member
You don't need to use Virtu either... If OpenCL is used instead of GPU encoding (Quicksync and the other variants for AMD/Nvidia) then it's compatible with every processor that can use OpenCL (which amounts to little more then a $30 addin graphics card). Intel IGPs for instance support OpenCL too.
 
T

Tak0r

Member
I'm not talking about GPU encoding .... Quicksync is a seperate hardware array specifically for h264 encoding inside the graphics of the cpu... it's NOT gpu encoding... as for opencl: It depends on your Drivers. Some are reportet to simply not work or being unstable.
 
B

Bensam123

Member
Quicksync is GPU encoding for Intel IGPs and gives quality similar to it. I think this is a dispute of semantics though.

GPU encoding for me is Quicksync, Video Codec Engine (AMD), and NVENC (NVidia), compared to GPU assisted encoding is OpenCL or using the GPU in a way to augment the encoding process without using dedicated features for it.

I haven't heard anything about OpenCL being unstable... perhaps on Intel IGPs, but Nvidia and AMD both support OpenCL as well. OpenCL is also supported on budget cards which can be had for $30-20 if your processor doesn't have a IGP. Specifically Intel as AMD has IGPs too, but they don't use Quicksync.
 
T

Tak0r

Member
No, Quicksync is a dedicatet hardware implementation of h264, well with a limited feature set. The same thing is NVEnc and VCE but not CUDA or OpenCL which are just gpgpu.

As for driver stability read http://forum.doom9.org/showthread.php?t=164960. Seems to be fixed in current Drivers. It might be nice but could lead to more frustration if bugs appear, so i only would recommend this for advanced users in a closed tester group.
 
G

Grimio

Member
Hello,
you probably heard about this already, the new Intel Media SDK got released recently with the licence permitting the use in open source software.

It's still just the high level calls to the mostly pre-set QuickSync(so we won't have true QuickSync enabled x264 any time soon). Still, it would provide a great option to replace the x264 on enabled CPU's to completely free up the resources for highly demanding games.

I would love to see this feature implemented, as would others I assume :)

http://software.intel.com/en-us/forums/topic/356800
 
M

Muf

Forum Moderator
Grimio said:
Hello,
you probably heard about this already, the new Intel Media SDK got released recently with the licence permitting the use in open source software.

It's still just the high level calls to the mostly pre-set QuickSync(so we won't have true QuickSync enabled x264 any time soon). Still, it would provide a great option to replace the x264 on enabled CPU's to completely free up the resources for highly demanding games.
Click to expand...
That's great news. High level calls are all you can ever expect to get, as Quick Sync is by definition a high level implementation of the h.264 codec. It's all hardwired in silicon (this is what "discrete implementation" means) so there is probably very little programmable about it.

A prerequisite of this being implemented in OBS (aside from needing a motivated developer to write it) will be refactoring output to be modular so that different encoders can be selected, which is a planned feature.
 
You must log in or register to reply here.
Top