Hardware transcoding not working on Intel CPU

[daldana 122]

Here are my logs after installing the version from Post #18. FYI, the Quicksync decoders each took about a minute to start a Live TV stream and the DX11VA decoder took about 3-5 seconds.

ffmpeg-transcode-DX11VA Decoder.txt

ffmpeg-transcode-QuickSync Intel(R) HD Graphics - D3D11 Decoder.txt

ffmpeg-transcode-QuickSync Intel(R) HD Graphics Decoder.txt

[softworkz 5066]

@@daldana - Thanks a lot for trying!

 

Could you do a quick check if it's working with the stable ffmpeg from post #22?

[daldana 122]

Ok, using the file from post #22, here are my logs attached. 

 

It's interesting that with this ffmpeg, using the Quicksync decoders with the Quicksync encoder (not the D3D version) produced very smooth playback. Also using the Quicksync Intel ® HD Graphics decoder with the Quicksync Intel ® HD Graphics - H.264 (AVC) was showing only 1.3% CPU in Windows Task Manager.

ffmpeg-transcode-3ef77fb8-568c-4849-af03-8719a13d53c7_1.txt

ffmpeg-transcode-539c3b91-652f-4d92-92a6-74c5ef196236_1.txt

ffmpeg-transcode-a95d515f-2b89-42de-ab90-989829ebae09_1.txt

[snitchy 3]

@@softworkz Sorry for the delay in replying - I've tried the two commands that you posted but unfortunately I got the same error message as I always get. I did also try it for the older ffmpeg and the newer one you posted, but got the same results I'm afraid.

 

Do appreciate your continued efforts though

[Luke 42077]

@@daldana

@@snitchy

 

If any of you would like to try the beta server that would be helpful as it has a newer ffmpeg build that might make a difference. Thanks.

[softworkz 5066]

@@daldana
@@snitchy
 
I'm quite confident that it will work for both of you now...

 

Please retry if you got a chance to do so.

[snitchy 3]

Hello again,

 

Firstly, really sorry for taking a while to get back to you, I've just had a really busy few weeks so haven't had a chance to test this out for you.

 

I've just given it a ago now and I'm sorry to say it still reverted back to software encoding I've attached the logs so you can see, and I'll be happy to test anything else if you want me to change any of the settings. Just let me know.

ffmpeg-transcode-f7066b04-d48e-48dc-9649-30bde30f8789_1.txt

[softworkz 5066]

@@snitchy - Thanks for the log

 

Would you be able to run the following command line and see whether it works:

P:\Emby\system\ffmpeg.exe -loglevel +timing -hwaccel qsv -hwaccel_device hw -qsv_device 0 -c:v h264_qsv  -f matroska -i file:"\\walle\Movies\Ghostbusters (1984)\Ghostbusters (1984) Bluray-1080p.mkv" -threads 0 -map 0:0 -map 0:1 -sn -c:v:0 h264_qsv -b:v:0 1116000 -maxrate 1116000 -bufsize 2232000 -preset veryfast -profile:v:0 high -level:v:0 4.0 -g:v:0 72 -keyint_min:v:0 72 -sc_threshold:v:0 0  -copyts -vsync -1 -codec:a:0 ac3 -metadata:s:a:0 language=eng -disposition:a:0 default -ac:a:0 6 -ab:a:0 384000 -ar:a:0 48000  -f segment -max_delay 5000000 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 -start_at_zero -segment_time 3  -individual_header_trailer 0 -segment_format mpegts -segment_write_temp 1 -segment_list_type m3u8 -segment_start_number 0 -segment_list "P:\Emby\programdata\transcoding-temp\fb08243efa127b38a03eb9ecbfb01e78.m3u8" -y "P:\Emby\programdata\transcoding-temp\fb08243efa127b38a03eb9ecbfb01e78%d.ts"

Thanks.

[softworkz 5066]

@@snitchy @@daldana

 

Today's beta (4.4.0.5) comes with a new ffmpeg version (2020-01-01) for Windows including some fixes for QuickSync.

 

It would be great if you could try that new version and let us know about the results.

 

Thanks,

softworkz

[vdatanet 1617]

In beta 4.4.0.5 for Linux, transcoding does not work (not hardware, not software).

 

I get this error:

08:42:59.600 Unrecognized option 'print_graphs_file'.
08:42:59.600 Error splitting the argument list: Option not found

Examples:

ffmpeg-transcode-2cd5d566-1abc-4987-9496-e9d6962b9d85_1.txt

ffmpeg-transcode-fd77fa62-439e-4195-bb65-7b1f60d667a3_1.txt

embyserver-63713724492.txt

hardware_detection-63713724497.txt

Edited January 4, 2020 by vdatanet

[softworkz 5066]

@@vdatanet - Thanks a lot for the quick feedback! A version check got lost but we've already fixed it. New packages are currently being built. This may take a while..

[vdatanet 1617]

@@vdatanet - Thanks a lot for the quick feedback! A version check got lost but we've already fixed it. New packages are currently being built. This may take a while..

 

Tested new build and transcoding is fixed. Thanks!

[daldana 122]

Attached are my logs, there are three sets one for each decoder option (all of the -1's go together, then the -2's, etc). The regular Quicksync HD decoder and the DX11VA decoder both worked great between 8% and 12% CPU for Live TV viewing. The D3D version took almost a full minute to start the video and once it did start, it's CPU usage was around 15%.

embyserver-1.txt

ffmpeg-transcode-92cb5dec-8a81-4bc9-ab38-974268f3a618_1-1.txt

hardware_detection-63713829699-1.txt

embyserver-63713829681-2.txt

ffmpeg-transcode-bff3ea42-5b8f-46c2-8df2-169c8a819fd9_1-2.txt

hardware_detection-63713829155-2.txt

embyserver-63713829138-3.txt

ffmpeg-transcode-fd5bebae-efc6-416d-8de8-de405bed6ba3_1-3.txt

hardware_detection-63713828807-3.txt

[softworkz 5066]

@@daldana - Do you have a monitor connected to the onboard graphics of the machine on which you're running Emby server?

 

Are you working on that machine directly or via remote desktop?

[daldana 122]

softworkz,

 

I do have a monitor connected to the server, but I was working on it via remote desktop. The device I was using to view the video was an Android smart phone.

[softworkz 5066]

Just recently we had another case where a remote desktop connection had totally disabled all hw acceleration.

 

You should read through this topic: https://emby.media/community/index.php?/topic/80319-question-about-quicksync-and-rdp/?p=821645

 

Please try one of the suggestions and let us know how it works out.

[daldana 122]

softworkz,

 

I have both the stable server version and the beta version running on the same PC, so I'm curious as to why the stable version uses hardware acceleration but the beta version doesn't. I used a web browser to monitor the settings dashboard of both, not via remote desktop. I've attached the ffmpeg logs, the stable version is the 9:13pm and the beta version was at 9:11pm. Thanks for taking a look at the logs.

 

Dave

 

ffmpeg-transcode-0bd9714b-61a5-4a94-b1bc-62a55171a2fe_1.txt

ffmpeg-transcode-b156f273-1aac-478f-97a8-fb490b4aaff0_1.txt

[softworkz 5066]

Thanks for the new logs, I'll need a while trying to replicate this.

 

One question: Are you seeing the same behavior when you play recorded tv instead of live tv?

[softworkz 5066]

One question: Are you seeing the same behavior when you play recorded tv instead of live tv?

 

And: Does it also fail when the decoder is H.264 instead of mpeg2?

(I mean with a different video file)

Edited January 11, 2020 by softworkz

[daldana 122]

Recorded TV behaves the same way on both servers, acceleration on stable but not on beta, but with an H.264 file I get acceleration on both servers. I've attached the ffmpeg file from the beta server. 

[daldana 122]

Sorry, file attached now.

ffmpeg-transcode-cd2968a4-f069-4d66-a590-8fcbf7f19e47_1.txt

[softworkz 5066]

Thanks, that's very good information, as that boils it down to be an issue with the QuickSync Mpeg2Decoder in the recent betas.

 

Please hold on, I'll post here as soon as I got some news on the issue!

Edited January 11, 2020 by softworkz

[softworkz 5066]

I'm glad too tell that this problem has been fixed and the fix will be included in the next beta

 

Thanks for reporting!

[daldana 122]

Great! Can't wait to check it out!

[Luke 42077]

It's up in case you'd like to try it out. Thanks.