GPU Transcoding (Intel QuickSync and nVidia NVENC)

[Luke 42077]

Yes it's possible in a future update.

[millsii 8]

Yes it's possible in a future update.

 

Good one, thanks for the response!

[devnull22 0]

Hi all! Relatively new user to emby, and been reading up somewhat on this thread to see if I can squeeze out more performance for my emby setup. 

 

I've setup a proxmox server on a small J1900 cpu board, which some people confirm support vaapi here. I've downloaded a ffmpeg that support vaapi (https://johnvansickle.com/ffmpeg/). As I run emby into a container, I've also mounted the /dev/dri folder into the container, so it should be able to use it. My actual problem comes not from the container, but also happens on the host, I get this error message on both host and container when trying to test out encoding with vaapi:

root@media-srv ffmpeg/ffmpeg-3.2.4# ./ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i nullsrc=s=1280x720 -t 1 -vf 'format=nv12,hwupload' -vcodec h264_vaapi -f null -
ffmpeg version 3.2.4-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 5.4.1 (Debian 5.4.1-5) 20170205
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-5 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gray --enable-libass --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzimg
  libavutil      55. 34.101 / 55. 34.101
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
[AVHWDeviceContext @ 0x575ef20] No VA display found for device: /dev/dri/renderD128.
[vaapi @ 0x30df1e0] Failed to create a VAAPI device

My google searches have not brought up much about it, and since it's not exactly "regular use-case" for proxmox, I wondered if anyone here knew what could be missing on the host (possibly kernel modules or drivers, used to linux but not that side of it). If I can't make it work, I might look for other ways to manage it, but so far, really like that I can run containers and some VMs on that small, low-power machine.

 

If any one can help, would be grateful, but I am aware that my setup is not that conventional! 

[Andy777 21]

No idea about proxmox, but could you post the output of "vainfo" on the host? That would tell a lot about the status off vaapi on the host. Note: the user needing access to /dev/dri need s to be included in th "video" group.

[nague 5]

I'm now able to use NVENC transcoding in my Emby VM thanks to a new host machine supporting VT-d !  I dedicated an old Quadro K600 for the job, it works quite well. I can see a real CPU benefit when transcoding.

 

I can run two ffmpeg threads in the same time (so two emby users), but the third one crash…   Here the output log:

 

[h264_nvenc @ 0x32453e0] OpenEncodeSessionEx failed: out of memory 
(10)
[h264_nvenc @ 0x32453e0] No NVENC capable devices 
found
Error initializing output stream 0:0 -- Error while opening encoder 
for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, 
width or height
[aac @ 0x320d380] Qavg: 65536.000
[aac @ 0x320d380] 2 frames left in the queue on 
closing
Conversion failed!

According to the nvidia-smi tool, I still have some free RAM on the K600 card… So I’m not sure it's a memory issue.

 

Edit:

Are you able to run more than 2 transcoding job with NVENC (maybe with a better graphic card ) ?

@Luke: would it be possible to silently retry transcoding without NVENC when this issue appears ?

 

Sorry, I'v just read that the question has already been asked few days ago  

Edited March 16, 2017 by nague

[Luke 42077]

There are some changes in the beta channel for nvenc so you could try that. Thanks.

[devnull22 0]

No idea about proxmox, but could you post the output of "vainfo" on the host? That would tell a lot about the status off vaapi on the host. Note: the user needing access to /dev/dri need s to be included in th "video" group.

 

Here's what I get from vainfo on the host:

root@proxmox:~# vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_36
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.36 (libva 1.4.1)
vainfo: Driver version: Intel i965 driver for Intel(R) Bay Trail - 1.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD

I did put the emby user in the video group, but even as root, running a test command gives the same error. Trying to find out what that error is... found some posts that seemed to say some intel modules did not initalize properly if a video card was not plugged in a monitor at boot, as this is headless, that could be a problem, will try later tonight to plug it in my tv and reboot.

[Andy777 21]

 

Here's what I get from vainfo on the host:

root@proxmox:~# vainfo
error: XDG_RUNTIME_DIR not set in the environment.
error: can't connect to X server!
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_36
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.36 (libva 1.4.1)
vainfo: Driver version: Intel i965 driver for Intel(R) Bay Trail - 1.4.1
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264StereoHigh         : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileJPEGBaseline           : VAEntrypointVLD

I did put the emby user in the video group, but even as root, running a test command gives the same error. Trying to find out what that error is... found some posts that seemed to say some intel modules did not initalize properly if a video card was not plugged in a monitor at boot, as this is headless, that could be a problem, will try later tonight to plug it in my tv and reboot.

 

There is probably nothing wrong with your vaapi. Tested the command line from your first post on my system and: Success on my self built ffmpeg. Failure on JVS release ffmpeg build and failure on JVS git build. You should probably test it with Emby generated real command line.

 

The test runs on my system are attached.

ffmpeg_vaapi_tests.txt

[sh0rty 714]

There are some changes in the beta channel for nvenc so you could try that. Thanks.

 

What scenario can we test to see changes?

[Luke 42077]

Just play a video and test for regressions.

[devnull22 0]

Wel, no good news. I had already tried the command generated by Emby, on the host. I actually tested a self compiled ffmpeg, with the same result when enabling vaapiwith the command you managed to run with yours. I might just find another way or buy a cheap gtx 710 to use nvenc instead when I need to stream remotely. Thanks for the help, Andy777, gonna try following this solution for nvidia, which should work: https://bradford.la/2016/GPU-FFMPEG-in-LXC

 

Same use case, just need to verify I can put that card in my small server case!

Edited March 18, 2017 by devnull22

[nague 5]

Luke, on 17 Mar 2017 - 6:14 PM, said:

Just play a video and test for regressions.

 

I've just tried last beta: same issue, third transcoding failed with same error:

[h264_nvenc @ 0x28005a0] OpenEncodeSessionEx failed: out of memory 
(10)[h264_nvenc @ 0x28005a0] No NVENC capable devices found 

[Luke 42077]

 

I've just tried last beta: same issue, third transcoding failed with same error:

[h264_nvenc @ 0x28005a0] OpenEncodeSessionEx failed: out of memory 
(10)[h264_nvenc @ 0x28005a0] No NVENC capable devices found 

 

Well that doesn't look related to Emby Server. What happens if you take the same command line from the ffmpeg log and run it manually?

[nague 5]

Oh no, it's not an Emby issue: ffmpeg and/or cuda can't handle more than 2 nvenc threads. Like @@Gerrit507 proposed in post #982, Emby should perform a CPU fallback when this error appears. I thought you implemented it in beta.

Edited March 20, 2017 by nague

[Luke 42077]

No we haven't looked at a cpu fallback yet.

[freezy 2]

No we haven't looked at a cpu fallback yet.

 

Is that something you're already working on, or would you accept a PR for such a feature?

 

Basically just a retrial when ffmpeg fails with nvenc enabled. Wouldn't even need to check for open transcoding sessions since nvenc could also be unavailable due to reasons unrelated to Emby.

[Luke 42077]

Yea I would imagine a retry is all it would be.

[jscoys 147]

Hello @@Luke and all of you testing those wonderful hardware decoding solutions Emby is bringing ;-)

 

First observation for NVENC decoding with Zeranoe Build from 21st of March and a Geforce Gtx 750 ti :

- I tried from IOS Client (My Iphone) and two movie files (MKV container, H 264) so it's expecting to transco or convert the envelop, so at least from the MKV to mp4...

1) If i play from the beginning it seems great. I tried only 10 minutes.

2) If i seek, problems start... First observation : the video is very long to start after a seek. It seems that with NVENC activated it doesn't deliver quickly the first seconds of playback by reducing the picture quality (like it does when it uses the CPU). So the picture is perfect right after seeking, but it takes two / three more times to start the playback compared to a CPU transco...

3) After seeking, subtitles are always desync. They are systematically appearing before the timeline they are supposed to pop and it could be from 10 to 40 seconds of desync. Maybe linked to the time playback needs to start?

 

Hope these observations would help, let me know if you need me to go deeper by doing some different tests with my Iphone or other clients (I have a Chromecast and Emby Theatre) and providing logs.

[Luke 42077]

Thanks for the feedback.

[Jdiesel 1431]

I didn't read this entire thread so I apologize if it has already been mentioned but I am looking for a real world example of what VA API transcoding can do with a mid to high end GPU. My understanding is that VA API isn't limited to a certain number of simultaneous encodes like NVENC. So what is the limiting factor? Number of stream processors? Overall memory transfer rate? Amount of memory?

 

I am looking for something that can process approximately 10 simulations 1080p streams, is this even possible?

[CheatHacker 0]

Just i would like to Thank you for this

[Luke 42077]

Enjoy

[voxadam 1]

Why does Emby default to using /dev/dri/card0 as the VA-API device on Linux? If Emby is being run on a system where the user is using the CPU's integrated GPU to render their desktop, access to /dev/dri/card0 is going fail as that device node is already being used by Xorg or Xwayland.

 

In retrospect, getting hardware accelerated encoding/transcoding using QSV on my Fedora 25 system was fairly easy, but it did involve beating my head against the desk a few times before I realized exactly what needed to be done.

• Install ffmpeg from the RPM Fusion repo
• Add the user that is running Emby to the 'video' group
• Configure Emby to use VAAPI
• Configure Emby to use /dev/dri/renderD128

I haven't experienced a single issue since doing the above. Not only that but I see much lower CPU usage when a video requires transcoding.

[Luke 42077]

Hi @@voxadam, it's just a default and certainly you're right, on some systems another value might be more appropriate. That's why the value is on the transcoding settings page so that you can change it.

[bcm00re 18]

So is it a known problem that QSV and NVENC hardware encoding currently has problems in Emby (with the server running on a win10 PC)? I haven't been able to get it to consistantly on live streams, and others who had it working have told me it's currently broken. Others in this thread have reported stable/solid performance, but I am not seeing that at all. I first was using version of ffmpeg that comes with Emby (April 2016 version it appears) but today I tried the released 3.2.4 Zeranoe version mentioned in this thread, but both work equally as bad.