Linux - Recommendations for GPU to transcode and stream

[johnInHolyrood]

I've had fairly good luck using Debian Linux, VLC, x264 and a i7-3770k to groom and stream some satellite video feeds. One machine is processing two mpeg2 HD channels to mpeg4 in real time. That system is documented in earlier postings on this forum.

I'd like to use an older Xeon x5450 multicore server for the same function with the addition of a graphics card/gpu. Can anyone recommend a Linux distro and graphics card that could match or exceed the performance of the i7-3770k based system? About a year ago I tried my hand at integrating a nvidia/cuda based card but had little luck getting reliable performance. The distros I used then were very hard to get the card integrated into the op system.

[Jean-Baptiste Kempf]

Debian is always a good idea. Does your Xeon support QSV?

[johnInHolyrood]

Thank you for the response. The Xeon x5450 does not support Quick Sync Video. I am running Debian Squeeze on the i7-3770k machines, and had tried to get the nVidia hardware enabled on it but had trouble. I will give a more modern Debian release a try, both on the x5450 and the i7-3770k. I also have an openSuse 13.1 distribution to try.

Going down a related tangent, my desktop machine is a Intel Core 2 Q8300 runnning Windows 7. It won't quite handle live grooming and streaming a single HD channel. I have tried adding an nVidia GT 520 (40 core) and an nVidia GT 640 (384 core) with vlc 2.1.3 with hardware acceleration turned on. The CPU load is less, but the quality still isn't good. I'm interpreting this as the encoder is running on the CPU despite the beefed up GPU, and the Q8300 CPU is not up to the encoding task. The reduction in CPU load comes from the decode being shifted the GPU. Anyone feel free to comment on this interpretation. Is there a way to know what is running on the CPU and what is running on the GPU. I question whether Linux versions of VLC and its encoders are also currently constrained in this manner and whether it is a waste of time to try loading a Linux based test system for the Q8300 to see if there is a different result.

[johnInHolyrood]

Is there a way to confirm from the CLI debug output that hardware decoding is actually being used?

I have a test platform: a Dell Poweredge 1950 rack server with a Xeon L5240 @ 3.00GHz with a PCIe x8 to x16 adapter into which is inserted an an nVidia GT 640. I intend to test other GPUs to compare. The operating system is Opensuse 13.1 with nvidia propietary drivers installed and vlc 2.1.4. In the VLC GUI, video setting, under hardware decode acceleration, I've set "automatic". The machine is then being told by a command script to transcode an mpeg2 stream to mpeg4. The command script includes -vvv so there is a lot of debug output. I then use another script running uptime every 60 seconds to get a feel for cpu loading. I will record a standard video to use from test to test so comparisons are uniform. I will test with the machine in runlevel3 to see how much having a graphics user interface costs transcoding capabilities. I am able to use netrounds IPTV monitoring to record and graph output stream impairments during test runs.

If someone has comments about how much the PCIe x8 to x16 cable might limit the GPU/CPU communication and cooperation, feel free to share them.

[johnInHolyrood]

On the test server, the nVidia-settings utility shows GPU usage. If I use VLC to display a stream the usage goes up to 10%, good. If I ask VLC to transcode the stream, the nVidia GPU usage never changes from zero percent usage, not so good.

Are there settings to get VLC to use the GPU for decode when transcoding?

[johnInHolyrood]

I've installed an AMD/ATI 7730 GPU in the same OpenSuse 13.1 based Dell Poweredge 1950 server and installed the AMD proprietary driver. I can't see that VLC is taking advantage of the GPU during the transcoding. What am I missing? Would I have better results by testing a VLC 2.2 build?

[Rémi Denis-Courmont]

You would need VLC 2.2 and libav 10 both built with VDPAU support, and of course a working VDPAU device driver.

The Gallium VDPAU state tracker was quite buggy initially. I don't know how much it's improved, so YMMV.

[johnInHolyrood]

Thank you for the response, you give me hope! I will also consider the notes at http://www.remlab.net/op/vlc-vdpau.shtml. I will plug the NVidia GT 640 card back into the test server and work on building VLC 2.2 and libav 10. I am assuming the 1-click installation of the OpenSuse 13.1 nVidia driver gave me a working VDPAU device driver, but will try to find out how to prove that. Any comments or direction are greatly appreciated. Although it is not my current primary job, I have a lot of experience reading and writing C and assembler code from work in the 80s/90s, so maybe I can see my way through some bugs as well. Thank you again.