Hardware Transcoding Not Working Kaby Lake

[PatsFan87 1]

I am using jellyfish samples without any audio. They are all the same mbps, just different codecs. I am doing this over home network, no bandwidth issues. 

[Guest asrequested]

And everything other than HEVC, plays with no issues? Sorry, I'm on my phone, you may have answered that, already.

[PatsFan87 1]

Seems so.

[PatsFan87 1]

After even more testing. I am getting errors from ffmpeg via cmd when trying to go from h264 to hevc, or hevc to h264, or hevc to hevc. The errors say that the bot rate is not supported by qsv, even though they should be. I have tried various modifiers to try to use different bit rate modes but none worked. Should I try to swap a drive and load unbuntu and use vaapi?

[Luke 37231]

We do support vaapi so yes you could try that.

[PatsFan87 1]

I was able to get the hardware decoding on a 4k HEVC 10-bit mkv working with Unbuntu using VAAPI. I had to add emby to the video group otherwise it threw an error about no VA device detected. 

 

So, my hardware works and it must be an issue with ffmpeg the intel driver not giving access to the hevc-qsv, I guess.

[Luke 37231]

Thanks for the feedback.

[PatsFan87 1]

On unbuntu with vaapi activated. I am still having issues. It does seem to be using hardware tramscoding, but I. Only getting ~.9 speeds when trying to transcode to a 4k output. This means every minute or so it stops to buffer. This seems to go away if I lower the playing quality to 1080p or 720p. Any ideas?

[Luke 37231]

4k HEVC 10-bit requires a fair amount of resources. If you're doing a full video transcode then you may need to lower the quality in order to sustain a playable rate.

 

The other option would be to use an Emby app that can direct play hevc without transcoding.

[Waldonnis 148]

Sorry about the delay.  I have relatives in town, so I've been frazzled.

 

I'm not keen on seing the "no device available" error.  This is usually indicative of the iGPU not being connected to anything or being disabled.  I realise I'm behind a bit on this thread, but is there a monitor connected to the iGPU and is the integrated graphics enabled in the BIOS?  Also, can you post a transcode log from the Ubuntu side, since the transcoding rate seems awfully slow?

 

Which bitrate of jellyfish file are you using, out of curiosity?  The Windows log you posted shows a source file bitrate that's significantly higher than anything you'll encounter otherwise.  It's nearly the max for the UHD spec, actually, but there are no actual discs that I know of with bitrates that high other than maybe a spec test disc.  It's probably overkill to test bitrates that high unless you have an application in mind or source material that actually uses such bitrates.

 

FYI, the ratecontrol mode error is an overly generic error, unfortunately.  It could normally be caused by anything from frame dimensions to bitrate to lookahead being on with iGPUs that don't support it (like mine).

[Guest asrequested]

Something to consider. When they designed the gen 7, they combined it's functionality with the Z270 chipset. The full features of the GPU would only be available in conjunction with the Z270. My understanding is that the chipset would actually be doing a good deal of the processing (specifically what, I don't know).  So here's my thought. Could this have something to do with the chipset drivers?

[Waldonnis 148]

Something to consider. When they designed the gen 7, they combined it's functionality with the Z270 chipset. The full features of the GPU would only be available in conjunction with the Z270. My understanding is that the chipset would actually be doing a good deal of the processing (specifically what, I don't know).  So here's my thought. Could this have something to do with the chipset drivers?

 

I suppose it's possible, but I'm skeptical of anything they say about that because they usually talk generically about these types of things rather than specifying what operations require what.  Who knows whether they were talking about "everything" or solely about playback/other operations that might require certain levels of HDMI or HDCP support.  Sadly, figuring out what's actually required for this type of operation specifically would take a lot of info that I just don't have access to.  Every GPU manufacturer is guilty of this as well...they talk about the uses they think are common (live game streaming, 4k playback, etc) but don't ever cover or consider more niche cases like this, so you never know what they actually do until you try it and press their driver developers a bit with the results.

[PatsFan87 1]

I have tested 40mpbs jellyfish files as well as 120 and 140 ones. I'll get logs soon.

[PatsFan87 1]

Also the hardware not available error is explained here. Using the init command made three error go away, but the ratecontrol mode error kept happening.

 

https://trac.ffmpeg.org/ticket/6492

[PatsFan87 1]

And it looks like I crashed my Ubuntu system. Might take a awhile for the log.

[PatsFan87 1]

More updates:

 

I was able to get the hevc to h264 to go through in the cmd line. Apparently the pixel format is not compatible. I found information here: http://forum.doom9.org/archive/index.php/t-173793.html and I tried their command line and it worked. So, then I kept removing pieces until I found out it was the -pix_fmt parameter that was the issue. The transcoding is slow at about 0.5x on this Jellyfish bitrate test file (jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv). My cpu was 90-99% and my gpu was only 20%. So, it seems my cpu is still doing a lot of work even with the h264_qsv specified.

 

 

C:\Users\user\Desktop>ffmpeg -loglevel verbose -y -i test120.mkv -pix_fmt nv12 -c:v h264_qsv test123.mkv

ffmpeg version 3.4.1 Copyright © 2000-2017 the FFmpeg developers

  built with gcc 7.2.0 (GCC)

  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx

  libavutil      55. 78.100 / 55. 78.100

  libavcodec     57.107.100 / 57.107.100

  libavformat    57. 83.100 / 57. 83.100

  libavdevice    57. 10.100 / 57. 10.100

  libavfilter     6.107.100 /  6.107.100

  libswscale      4.  8.100 /  4.  8.100

  libswresample   2.  9.100 /  2.  9.100

  libpostproc    54.  7.100 / 54.  7.100

Input #0, matroska,webm, from 'test120.mkv':

  Metadata:

    COMPATIBLE_BRANDS: iso4hvc1iso6

    MAJOR_BRAND     : iso4

    MINOR_VERSION   : 1

    ENCODER         : Lavf56.3.100

  Duration: 00:00:30.10, start: 0.067000, bitrate: 119845 kb/s

    Stream #0:0(und): Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv), 3840x2160 [sAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 29.97 tbc (default)

    Metadata:

      CREATION_TIME   : 2016-02-05 13:00:09

      LANGUAGE        : und

      HANDLER_NAME    : hevc@GPAC0.5.2-DEV-rev565-g71748d7-ab-suite

Stream mapping:

  Stream #0:0 -> #0:0 (hevc (native) -> h264 (h264_qsv))

Press [q] to stop, [?] for help

[graph 0 input from stream 0:0 @ 000001b4612cf6c0] w:3840 h:2160 pixfmt:yuv420p10le tb:1/1000 fr:2997/100 sar:1/1 sws_param:flags=2

[auto_scaler_0 @ 000001b46a6ff520] w:iw h:ih flags:'bicubic' interl:0

[format @ 000001b4612d1e20] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_null_0' and the filter 'format'

[auto_scaler_0 @ 000001b46a6ff520] w:3840 h:2160 fmt:yuv420p10le sar:1/1 -> w:3840 h:2160 fmt:nv12 sar:1/1 flags:0x4

[h264_qsv @ 000001b4602b4120] No device available for encoder (device type qsv for codec h264_qsv).

[h264_qsv @ 000001b4602b4120] Initialized an internal MFX session using hardware accelerated implementation

[h264_qsv @ 000001b4602b4120] Using the VBR with lookahead (LA) ratecontrol method

[h264_qsv @ 000001b4602b4120] profile: high; level: 51

[h264_qsv @ 000001b4602b4120] GopPicSize: 250; GopRefDist: 4; GopOptFlag: closed ; IdrInterval: 0

[h264_qsv @ 000001b4602b4120] TargetUsage: 4; RateControlMethod: LA

[h264_qsv @ 000001b4602b4120] TargetKbps: 4261; LookAheadDepth: 40

[h264_qsv @ 000001b4602b4120] NumSlice: 1; NumRefFrame: 2

[h264_qsv @ 000001b4602b4120] RateDistortionOpt: OFF

[h264_qsv @ 000001b4602b4120] RecoveryPointSEI: OFF IntRefType: 0; IntRefCycleSize: 0; IntRefQPDelta: 0

[h264_qsv @ 000001b4602b4120] MaxFrameSize: 6220800; MaxSliceSize: 0;

[h264_qsv @ 000001b4602b4120] BitrateLimit: ON; MBBRC: OFF; ExtBRC: OFF

[h264_qsv @ 000001b4602b4120] Trellis: auto

[h264_qsv @ 000001b4602b4120] RepeatPPS: ON; NumMbPerSlice: 0; LookAheadDS: 2x

[h264_qsv @ 000001b4602b4120] AdaptiveI: unknown; AdaptiveB: unknown; BRefType: off

[h264_qsv @ 000001b4602b4120] MinQPI: 0; MaxQPI: 0; MinQPP: 0; MaxQPP: 0; MinQPB: 0; MaxQPB: 0

[h264_qsv @ 000001b4602b4120] Entropy coding: CABAC; MaxDecFrameBuffering: 2

[h264_qsv @ 000001b4602b4120] NalHrdConformance: OFF; SingleSeiNalUnit: ON; VuiVclHrdParameters: OFF VuiNalHrdParameters: OFF

Output #0, matroska, to 'test123.mkv':

  Metadata:

    COMPATIBLE_BRANDS: iso4hvc1iso6

    MAJOR_BRAND     : iso4

    MINOR_VERSION   : 1

    encoder         : Lavf57.83.100

    Stream #0:0(und): Video: h264 (h264_qsv), 1 reference frame (H264 / 0x34363248), nv12, 3840x2160 [sAR 1:1 DAR 16:9], q=2-31, 1000 kb/s, 29.97 fps, 1k tbn, 29.97 tbc (default)

    Metadata:

      CREATION_TIME   : 2016-02-05 13:00:09

      LANGUAGE        : und

      HANDLER_NAME    : hevc@GPAC0.5.2-DEV-rev565-g71748d7-ab-suite

      encoder         : Lavc57.107.100 h264_qsv

    Side data:

      cpb: bitrate max/min/avg: 0/0/1000000 buffer size: 0 vbv_delay: -1

No more output streams to write to, finishing.e=00:00:28.12 bitrate=3783.4kbits/s speed=0.516x

frame=  900 fps= 16 q=-0.0 Lsize=   15680kB time=00:00:29.96 bitrate=4286.9kbits/s speed=0.542x

video:15672kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.053459%

Input file #0 (test120.mkv):

  Input stream #0:0 (video): 900 packets read (450865199 bytes); 900 frames decoded;

  Total: 900 packets (450865199 bytes) demuxed

Output file #0 (test123.mkv):

  Output stream #0:0 (video): 900 frames encoded; 900 packets muxed (16047902 bytes);

  Total: 900 packets (16047902 bytes) muxed

[Luke 37231]

That's interesting. @@Waldonnis what do you think about changing the pix_fmt when quicksync is used?

[Waldonnis 148]

Interesting, but kinda expected since QuickSync only accepts a small number of pixel formats: nv12, p010le, and qsv (with qsv being an internal format).  I haven't seen too many cases where one would need to explicitly specify a conversion like that (outside of raw video footage) since it's often just handled internally and automatically, but it's possible that the wrapper just doesn't do it on its own.

 

From the command line, it looks like software decoding is being used, which explains a lot of the CPU use, minus the usual demuxing and frame copying overhead.  Another thing is that no scaling is being done, so the output is 2160p and 10bit, a combo which isn't well supported for playback on just about any device and will encode more slowly (just fyi; this is a testing scenario, so it's not a big deal, but something to be aware of).  The encoding side can definitely work faster, but it's probably bottlenecked by the software decoding speed.

 

Can you try the following command line:

ffmpeg -loglevel verbose -y -c:v hevc_qsv -i test120.mkv -pix_fmt nv12 -c:v h264_qsv test123.mkv

I suspect it may not work properly, but I'd like to see the error if it doesn't (it may still transcode, but it'll be awfully slow since it'll fall back to software encoding silently).  All this does is enable QuickSync hardware decoding, which fails in some hardware configurations, so it will also be interesting to see if you see the same issues with your configuration that I have with a significantly different setup.  There's a third way of doing it (all internal with no frame copying to system memory), but it's not worth testing since Emby can't use it for technical reasons beyond their control and has significant limitations otherwise.

 

@@Luke, I'm not sure quite yet and will have to think about cases where a different pixel format may be required and why (can't think of any offhand with 4:2:0 input, but I haven't thought too much about it yet).

[PatsFan87 1]

With your suggested cmd line:

 

C:\Users\user\Desktop>ffmpeg -loglevel verbose -y -c:v hevc_qsv -i test120.mkv -pix_fmt nv12 -c:v h264_qsv test123.mkv

ffmpeg version 3.4.1 Copyright © 2000-2017 the FFmpeg developers

  built with gcc 7.2.0 (GCC)

  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx

  libavutil      55. 78.100 / 55. 78.100

  libavcodec     57.107.100 / 57.107.100

  libavformat    57. 83.100 / 57. 83.100

  libavdevice    57. 10.100 / 57. 10.100

  libavfilter     6.107.100 /  6.107.100

  libswscale      4.  8.100 /  4.  8.100

  libswresample   2.  9.100 /  2.  9.100

  libpostproc    54.  7.100 / 54.  7.100

Input #0, matroska,webm, from 'test265.mkv':

  Metadata:

    COMPATIBLE_BRANDS: iso4hvc1iso6

    MAJOR_BRAND     : iso4

    MINOR_VERSION   : 1

    ENCODER         : Lavf56.3.100

  Duration: 00:00:30.10, start: 0.067000, bitrate: 119845 kb/s

    Stream #0:0(und): Video: hevc (Main 10), 1 reference frame, yuv420p10le(tv), 3840x2160 [sAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 29.97 tbc (default)

    Metadata:

      CREATION_TIME   : 2016-02-05 13:00:09

      LANGUAGE        : und

      HANDLER_NAME    : hevc@GPAC0.5.2-DEV-rev565-g71748d7-ab-suite

[AVHWDeviceContext @ 00000257a59967c0] Using D3D9Ex device.

Stream mapping:

  Stream #0:0 -> #0:0 (hevc (hevc_qsv) -> h264 (h264_qsv))

Press [q] to stop, [?] for help

[hevc_qsv @ 00000257a71651a0] Could not load the requested plugin '15dd936825ad475ea34e35f3f54217a6': specified object was not found (-9)

[hevc_qsv @ 00000257a71651a0] Error loading plugins

[hevc_qsv @ 00000257a71651a0] Error initializing an MFX session

Error while decoding stream #0:0: Function not implemented

[hevc_qsv @ 00000257a71651a0] Could not load the requested plugin '15dd936825ad475ea34e35f3f54217a6': specified object was not found (-9)

 

 

The missing plugin error repeats until I hit 'q'. 

 

H264 is also giving me issues it seems.

 

[h264_qsv @ 000001ffc7b20a20] Error during encoding: device failed (-17)peed=   0x

Video encoding failed

 

This is the command I am getting when try to convert a h264 file using no arguments on the cmd line.

If I do: ffmpeg -init_hw_device qsv:hw -i test264.mkv -c:v h264_qsv test123.mkv

 

It starts the process, but is still at slow speeds. 

[Waldonnis 148]

Huh, I didn't expect to see a plugin error like that on KL.  It usually indicates that it couldn't use/find a hardware decoder for that codec, but that shouldn't be happening with HEVC on KL (I'd see this on IB, but IB isn't capable of hardware decoding HEVC).  Could be driver related, but I'm not sure.  Is this using the Intel-provided driver or the one from Microsoft?  Also, is there another GPU installed in the system?

 

Fair warning, the init_hw_device option is tricky and the arguments don't map to hardware like you'd expect.  The "hw/hw2/hw3/hw4" options seem to map to DXVA ids, so it's possible that hw (implied 1) isn't the device you'd expect it to be.  For example, I have to use hw3 for my configuration since the iGPU isn't the only GPU in the system nor the default.  Usually you'll see an MFX-related error if you have the wrong hwX argument, though.  This page from Intel's MFX docs describes each of those arguments a bit better than the ffmpeg docs do.  Without using other tools, finding the right hwX is largely trial and error, unfortunately, and autodetection still seems to be spotty.

[PatsFan87 1]

I am using the Intel generic driver. I have tried the one supplied by Dell (computer is a Dell), but it seemed buggy (Intel display manager crashed). I have no other gpu on the machine. Also, in bios I have HD 630 selected.

 

I should mention I am running this setup headless mainly using rdp to access everything. Sometimes I have to connect to a monitor when needed.

[Waldonnis 148]

I am using the Intel generic driver. I have tried the one supplied by Dell (computer is a Dell), but it seemed buggy (Intel display manager crashed). I have no other gpu on the machine. Also, in bios I have HD 630 selected.

 

I should mention I am running this setup headless mainly using rdp to access everything. Sometimes I have to connect to a monitor when needed.

 

Ah, yeah, headless can be a problem.  Windows won't load the display driver if the GPU isn't connected to anything.  You can fake it out by creating a dummy display for it which works on some motherboards, but I've heard some still require a physical connection.

 

The Intel generic driver should be fine, as it seems like it includes the MFX library routines.  I wouldn't blame Dell too much driver-wise...Intel's display manager is awful and I can reliably crash it on any system    I wish they'd just rewrite the thing one of these years.

[PatsFan87 1]

Well that got me thinking. Instead of rdp I used tightvnc to access my desktop. Running similar commands gives and error.

 

Hw_frames_ctx or hw_device_ctx needs to be set for decoding

[PatsFan87 1]

Ok I got h264 decoding and encoding to work using...

 

Ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mkv -c:v h264_qsv out.mkv

 

Omitting any of those options gave rise to fall back software decoding. However with this options I am seeing 7x speeds of a 50M bitrate h264 1080 video file with 90-100% GPU utilization.

 

With HEVC files I still cannot get results either going from h265 to h264 or h265 to h265. I get the same the rate control method error. An example of hevc to hevc:

 

Ffmpeg -hwaccel qsv -c:v hevc_qsv -load_plugin hevc_hw -i input.mkv -c:v hevc_qsv -load_plugin hevc_hw out.mkv

 

The load_plugin hevc_hw is needed otherwise I would get failed to load plugin errors.

 

I have tried all different options for the hevc_qsv encoder (taken from ffmpeg -h encoder=hevc_qsv) and nothing seems to work.

[Waldonnis 148]

Using a hwaccel approach is very limiting, unfortunately, as I've found out in the past.  It's fast, and it's very efficient, but it doesn't allow for more complex filtering.  This means you only have access to basic operations like scaling and deinterlacing usually.  To do more, you'd need to be able copy the decoded frames back into system memory for manipulation, which means not using the hwaccel.  Also, certain versions of the d3d stuff can't be used in certain contexts.  I know with d3d9, you couldn't access the routines if the program was a service (or service-like) since it required an interactive desktop.  d3d11 was supposed to change this, but I never checked it to be sure.  I seem to recall ffmpeg support for d3d11 contexts wasn't added until mid-2017 anyway, so I just never got around to trying it again.

 

I'm not sure why the hevc_qsv decoding code isn't loading for you, though, especially since the h264_qsv stuff is obviously able to load and execute.  You can try disabling lookahead (-look_ahead 0), since that's not supported on some (usually older) iGPUs, but I can't think of much else offhand that you could try.  That error is very generic, though, and unless you're seeing a plugin load error as well, it could mean just about anything.

 

Tell you what, try increasing the loglevel to trace instead of verbose.  It'll be a LOT of output, but it should give you a better indication of what's going on internally with ffmpeg.