nvenc not being used apparently

[WEHA 0]

So I bought a quadro to get nvenc decoding acceleration but only the cpu is used when I check with the nvidia-smi -q -d UTILIZATION command

When using the command in this thread: https://emby.media/community/index.php?/topic/10723-gpu-transcoding-intel-quicksync-and-nvidia-nvenc/page-57 

ffmpeg -hwaccel auto -i FILE -map 0:0 -c:v rawvideo -hide_banner -stats -report -loglevel 56 -f null NUL

 

I see the utilization go up to over 50%, a lot more than the 0% when emby instigates ffmpeg

Is it because the action being done by emby is not able to be hardware accelerated or is something wrong with the options sent to ffmpeg from emby?

 

ffmpeg log snippet:

 

ffmpeg.exe -i file:"sourcefile" -map 0:0 -map 0:2 -map -0:s -codec:v:0 copy -copyts -avoid_negative_ts disabled -start_at_zero -vsync -1 -map_metadata -1 -map_chapters -1 -threads 0 -codec:a:0 libmp3lame -ac 2 -ab 384000 -af "volume=2" -y tempfile

 

ffmpeg version N-85266-g1229007 Copyright © 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)
configuration: --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib
libavutil 55. 59.100 / 55. 59.100
libavcodec 57. 90.100 / 57. 90.100
libavformat 57. 72.100 / 57. 72.100
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 83.100 / 6. 83.100
libswscale 4. 7.100 / 4. 7.100
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
Input #0, matroska,webm, from 'file:sourcefile':
Metadata:
encoder : libebml v1.3.0 + libmatroska v1.4.1
Duration: 01:51:08.92, start: 0.000000, bitrate: 11263 kb/s
Chapter #0:0: start 0.000000, end 613.792000
Metadata:
title : 00:00:00.000
Chapter #0:1: start 613.792000, end 1188.083000
Metadata:
title : 00:10:13.792
Chapter #0:2: start 1188.083000, end 1840.750000
Metadata:
title : 00:19:48.083
Chapter #0:3: start 1840.750000, end 2526.375000
Metadata:
title : 00:30:40.750
Chapter #0:4: start 2526.375000, end 2965.250000
Metadata:
title : 00:42:06.375
Chapter #0:5: start 2965.250000, end 3583.375000
Metadata:
title : 00:49:25.250
Chapter #0:6: start 3583.375000, end 4267.458000
Metadata:
title : 00:59:43.375
Chapter #0:7: start 4267.458000, end 4823.042000
Metadata:
title : 01:11:07.458
Chapter #0:8: start 4823.042000, end 5442.833000
Metadata:
title : 01:20:23.042
Chapter #0:9: start 5442.833000, end 6113.833000
Metadata:
title : 01:30:42.833
Chapter #0:10: start 6113.833000, end 6295.375000
Metadata:
title : 01:41:53.833
Chapter #0:11: start 6295.375000, end 6668.917000
Metadata:
title : 01:44:55.375
Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x800, SAR 1:1 DAR 12:5, 24 fps, 24 tbr, 1k tbn, 48 tbc (default)
Stream #0:1(fre): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)
Metadata:
title : French DTS 1509kbps
Stream #0:2(ger): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)
Metadata:
title : German DTS 1509kbps
Stream #0:3(fre): Subtitle: subrip
Metadata:
title : French
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:2 -> #0:1 (dts (dca) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
Output #0, matroska, to 'tempfile':
Metadata:
encoder : Lavf57.72.100
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p(progressive), 1920x800 [sAR 1:1 DAR 12:5], q=2-31, 24 fps, 24 tbr, 1k tbn, 1k tbc (default)
Stream #0:1: Audio: mp3 (libmp3lame) (U[0][0][0] / 0x0055), 48000 Hz, stereo, fltp, 384 kb/s (default)
Metadata:
encoder : Lavc57.90.100 libmp3lame

[Luke 42086]

Hi there, can you please provide the complete log of an example? thanks.

[WEHA 0]

ffmpeg log attached

ffmpeg-remux-e3601df5-3d53-4e00-8f15-afd828e92411.txt

Edited July 30, 2017 by WEHA

[WEHA 0]

@@Luke do you need more to analyze this problem?

 

thanks!

[Waldonnis 148]

Since there's no video encoding or decoding happening in that log (it's just copying the video stream as-is), nvenc wouldn't be used at all.  In the log, ffmpeg is transcoding audio from DTS to mp3, but nvenc doesn't help with that.  Both nvenc and qsv both can only be used on video streams, not audio.

[WEHA 0]

']

I see, now that you mentioned I see the stream mapping (I'm new to ffmpeg logs)

I didn't expect it to use so much cpu just for audio.

Does ffmpeg say something in the logs when it's succesfully using nvenc?

Edited August 3, 2017 by WEHA

[Waldonnis 148]

']

I see, now that you mentioned I see the stream mapping (I'm new to ffmpeg logs)

I didn't expect it to use so much cpu just for audio.

Does ffmpeg say something in the logs when it's succesfully using nvenc?

 

DTS frequently takes more effort to transcode from than other codecs for a variety of reasons.  In fact, whenever I hear of someone saying an audio transcode is using a lot of processor time, I guess that it's a DTS source and am often correct 

 

ffmpeg logs are pretty easy to read once you get used to them.  While ffmpeg normally won't show explicitly what's going on under the hood at its default loglevel, there are three spots you can look at to get a general idea of what's being used...

 

The first is the command line options being used.  A -c:v (short for codec:video) found prior to a -i (specifies an input file) indicates what decoder to use.  In the case of nvenc, the decoder names will end in _cuvid.  QuickSync's all end in _qsv, and software decoders are often not specified or just appear as plain codec names like h264 or hevc.  Examples:

Software decoding with the decoder not specified since it'll be auto-detected anyway:
  ffmpeg -i file.mkv ...

NVENC decoding:
  ffmpeg -c:v h264_cuvid -i file.mkv ...

QSV decoding:
  ffmpeg -c:v h264_qsv -i file.mkv ...

The -c:v found after the -i indicates what encoder is being used.  For nvenc, they all end in _nvenc.  Likewise, QuickSync's all end in _qsv, but software encoders are less uniform (libx264 and libx265 are the most common, meaning h.264 and hevc software encoders respectively).  Examples:

Software encoding:
  ffmpeg -i file.mkv -c:v libx264 ...

NVENC encoding:
  ffmpeg -i file.mkv -c:v h264_nvenc ...

QSV encoding:
  ffmpeg -i file.mkv -c:v h264_qsv ...

There are ways to specify multiple input or output files and specify en/decoders for each input file or for specific stream IDs/output files, but I won't get into that stuff since you won't see those in an Emby log on the video side of things.

 

The second spot to look at is the Stream mapping section of the log.  Each stream that's being processed will be listed, along with its input and output en/decoders.  The format's pretty easy to figure out... input -> output.  The word "native" on the input side usually means it's using software decoding, but not always (it's quirky when using -hwaccel, but Emby doesn't use that so it's reasonable to assume native is software when you see it).  Here's some examples:

Software decoding, NVENC encoding:
  Stream #0:0 -> #0.0 (h264 (native) -> h264 (h264_nvenc))

NVENC decoding and NVENC encoding:
  Stream #0:0 -> #0.0 (h264 (h264_cuvid) -> h264 (h264_nvenc))

NVENC decoding and software encoding:
  Stream #0:0 -> #0.0 (h264 (h264_cuvid) -> h264 (libx264))

Last spot is the Output section. Encoder-wise, it mirrors what is shown in the Stream mapping, but it gives a little more detail on what the output is expected to be like in case you want to verify those details (framerate, dimensions, sample/display aspect ratios, etc.).  Examples:

Software encoding:
  Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), nv12, 1920x804 [SAR 1:1 DAR 160:67], q=-1--1, 23.98 fps, 1k tbn, 23.98 tbc (default)

NVENC encoding:
  Stream #0:0: Video: h264 (h264_nvenc) (Main) (H264 / 0x34363248), nv12, 1920x804 [SAR 1:1 DAR 160:67], q=-1--1, 2000 kb/s, 23.98 fps, 1k tbn, 23.98 tbc (default)

The same basic principles apply to the audio streams, but get a little more complex with stream mapping since many files will have multiple audio tracks and Emby will only want a specific one (same goes for subtitles).  If you're interested in that part of things, check out the ffmpeg docs about the -map option and those parts of logs will be easier to understand.

 

Personally, when I look at posted logs, I always look at the command line first. It contains everything that ffmpeg is being told to do.  Thus, if the specific hardware decoder or encoder isn't on the command line like you were expecting, then ffmpeg was never told to use them by Emby (and I wouldn't see any mention of them later in the log).  If they are there, ffmpeg will try to use them...and fail if it couldn't, so it's often very obvious when things go horribly wrong or when the operation isn't supported by the hardware (like trying to encode HEVC Main10 on a pre-Pascal nVidia card - it will just fail with an error).  I only really look at the rest of the log to confirm what I'm seeing on the command line or when checking for other potential issues, but verifying that info is a good habit to get into so you know where and what to look at if something else goes wrong.

 

Hope that helps     If you want some "practice" reading hardware transcoding-related logs, there are tons of transcode logs posted in the big hardware acceleration thread in the General Discussion section that you can look at.  It probably won't take long before you can quickly identify what's going on in any of them.  I also suggest checking out the ffmpeg docs if you're interested in learning about the other options used in the command lines in the logs.  A lot of them will require more video/audio/terminology knowledge to understand, but at least you'll get an idea of what's going on "under the hood", so to speak.  ffmpeg is a really powerful tool and can be fun/super-useful once you get past the initial learning curve.

Edited August 3, 2017 by Waldonnis