QSV Transcoding Failing

[Brian_Oblivion 4]

Hi,

Having troubling playing back an MKV in a web client.... namely Chrome running on windows. This emby instance is running in a docker container hosted on an Ubuntu server using an Intel A380 ARC graphics card.  

When I click play on this particular concert, Emby appears to spin up ffmpeg to transcode it. However, the transcoding (the encoding specifically) is failing with the errors noted in the log snippet below. I tried changing the encoder options (profile, presets etc) without success. 

Other types of media formats are hardware transcoded without issues. 

 
Any suggestions? 

###### (ffmpeg transcode log) ######################## 
 
>>>>>>  Hardware Decoders for vc1
        [X] QuickSync DG2 Arc A380 - VC-1

>>>>>>  Hardware Encoders for h264
        [X] QuickSync DG2 Arc A380 - H.264 (AVC)

>>>>>>  Selected Codecs
Decoder QuickSync DG2 Arc A380 - VC-1
        Adapter #0: 'DG2 Arc A380' Id:22181 (Driver: , Vendor: 32902, SDK Version: 1.255)
        Frame Sizes: 16x16...16384x16384 - Width Alignment: 2 - Height Alignment: 2
        Color Formats: NV12 - Bit Depths: 8

Encoder QuickSync DG2 Arc A380 - H.264 (AVC)
        Adapter #0: 'DG2 Arc A380' Id:22181 (Driver: , Vendor: 32902, SDK Version: 1.255)
        Max Bitrate: 234 Mbit/s - Frame Sizes: 32x32...4096x4096 - Width Alignment: 16 - Height Alignment: 16
        Color Formats: NV12 - Bit Depths: 8
        Profiles: Baseline Profile (Level 5.2), Main Profile (Level 5.2), High Profile (Level 5.2)

>>>>>>  FindVideoEncoder - MediaType: h264, UseHardwareCodecs: True, HWA-Mode: Advanced
Info    Checking: 'QuickSync DG2 Arc A380 - H.264 (AVC)'
Info    Check successful - selecting 'QuickSync DG2 Arc A380 - H.264 (AVC)'

>>>>>>  FindVideoDecoder - MediaType: vc1, UseHardwareCodecs: True, HWA-Mode: Advanced
Info    Checking: 'QuickSync DG2 Arc A380 - VC-1'
Info    Check successful - selecting 'QuickSync DG2 Arc A380 - VC-1'

>>>>>>  Processing Plan
        Name                                        CanDoInHW  WillDoInHW  Reason                                                 
        QuickSync DG2 Arc A380 - VC-1            >> True       True        Hardware Codec                                          
        VideoInput                               >> True       True        Same adapter (/dev/dri/renderD128), same hardware co... 
        VideoOutput                              >> True       True        Hardware encoder                                        
        QuickSync DG2 Arc A380 - H.264 (AVC)     >> True       True        Hardware Codec                                          

>>>>>>  Video Processing Steps for [0:0]: VC-1
        Step                    HW-Context   Format       SW-Format           Size   Next
        VC1_QSV              >> QSV          qsv          nv12           1920x1080 >> 

>>>>>  Non-Default Encoder Parameters
Warning EncoderParametersH264Qsv.Preset: Original:  Actual: medium
Warning EncoderParametersH264Qsv.BitrateMode: Original: Classic Actual: Cbr
Warning EncoderParametersH264Qsv.ProfileLimit: Original:  Actual: AvcProfileHigh

/bin/ffmpeg -loglevel +timing -y -print_graphs_file "/config/logs/ffmpeg-transcode-cfcb0464-82f6-49ae-bbee-89a135d28e2d_1graph.txt" -copyts -start_at_zero -init_hw_device "qsv=dev1:hw_any,child_device=/dev/dri/renderD128" -filter_hw_device dev1 -f matroska,webm -c:v:0 vc1_qsv -threads:v:0 1 -hwaccel:v:0 qsv -hwaccel_output_format:v:0 qsv -noautorotate -i "/concerts/Song_Remains_The_Same_wChapters.mkv" -map 0:0 -map 0:1 -sn -c:v:0 h264_qsv -b:v:0 22083231 -g:v:0 72 -maxrate:v:0 22083231 -keyint_min:v:0 72 -r:v:0 23.976024627685547 -preset:v:0 medium -profile:v:0 high -aud:v:0 1 -c:a:0 libmp3lame -ab:a:0 192000 -ac:a:0 2 -metadata:s:a:0 language=eng -disposition:a:0 default -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -map_chapters -1 -segment_format mpegts -segment_list "/transcode-temp/transcoding-temp/52025E/52025E.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -individual_header_trailer 0 -write_header_trailer 0 -segment_write_temp 1 "/transcode-temp/transcoding-temp/52025E/52025E_%d.ts"

22:58:33.160 ffmpeg version 5.1-emby_2023_06_25_p4 Copyright (c) 2000-2022 the FFmpeg developers and softworkz for Emby LLC
22:58:33.160   built with gcc 10.3.0 (crosstool-NG 1.25.0)
22:58:33.160 Execution Date: 2025-11-19 22:58:33
22:58:33.172 Input #0, matroska,webm, from '/concerts/Song_Remains_The_Same_wChapters.mkv':
22:58:33.172   Metadata:
22:58:33.172     encoder         : libebml v1.3.9 + libmatroska v1.5.2
22:58:33.172     creation_time   : 2019-12-15T01:59:52.000000Z
22:58:33.172   Duration: 02:17:42.92, start: 0.042000, bitrate: 22083 kb/s
22:58:33.172   Stream #0:0(eng): Video: vc1 (Advanced) (WVC1 / 0x31435657), yuv420p(bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], Level 3, 23.98 fps, 23.98 tbr, 1k tbn, Start-Time 0.042s
22:58:33.172     Metadata:
22:58:33.172       BPS-eng         : 19285363
22:58:33.172       DURATION-eng    : 02:17:42.880000000
22:58:33.172       NUMBER_OF_FRAMES-eng: 198111
22:58:33.172       NUMBER_OF_BYTES-eng: 19919080433
22:58:33.172   Stream #0:1(eng): Audio: truehd, 48000 Hz, 5.1(side), s32 (24 bit), Start-Time 0.042s (default)
22:58:33.172     Metadata:
22:58:33.172       title           : Surround 5.1
22:58:33.172       BPS-eng         : 2088412
22:58:33.172       DURATION-eng    : 02:17:42.880000000
22:58:33.172       NUMBER_OF_FRAMES-eng: 9915456
22:58:33.172       NUMBER_OF_BYTES-eng: 2157037866
22:58:33.172   Stream #0:2(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 640 kb/s, Start-Time 0.042s
22:58:33.172     Metadata:
22:58:33.172       title           : Surround 5.1
22:58:33.172       BPS-eng         : 640000
22:58:33.172       DURATION-eng    : 02:17:42.880000000
22:58:33.172       NUMBER_OF_FRAMES-eng: 258215
22:58:33.172       NUMBER_OF_BYTES-eng: 661030400
22:58:33.173 Stream mapping:
22:58:33.173   Stream #0:0 -> #0:0 (vc1 (vc1_qsv) -> h264 (h264_qsv))
22:58:33.173   Stream #0:1 -> #0:1 (truehd (native) -> mp3 (libmp3lame))
22:58:33.173 Press [q] to stop, [?] for help
22:58:33.174 [vc1_qsv @ 0x23d7c240] Error querying IO surface: unsupported (-3)
22:58:33.174 Error while decoding stream #0:0: Function not implemented
22:58:33.174 [vc1_qsv @ 0x23d7c240] More data is required to decode header
    Last message repeated 12 times
22:58:33.186 [vc1_qsv @ 0x23d7c240] Error querying IO surface: unsupported (-3)
22:58:33.186 Error while decoding stream #0:0: Function not implemented
22:58:33.187 [vc1_qsv @ 0x23d7c240] More data is required to decode header
    Last message repeated 12 times
22:58:33.194 [vc1_qsv @ 0x23d7c240] Error querying IO surface: unsupported (-3)
22:58:33.194 Error while decoding stream #0:0: Function not implemented
22:58:33.195 [vc1_qsv @ 0x23d7c240] More data is required to decode header
    Last message repeated 12 times

 

[Brian_Oblivion 4]

Nevermind. Appears I've answered my own question. 

Despite the card reporting it is supports DE-coding(mistakenly typed encoding) of VC-1, appears Intel dropped support for it in VAAPI or something along those lines. So I unchecked this under the advanced hardware transcoding settings so the CPU will handle it. 

Hope it at least helps someone else! 

(and a suggestion to Emby devs, remove checking that decoder open by default - ignoring what the card reports).

[Luke 42077]

HI, thanks for following up !

[softworkz 5066]

@Brian_Oblivion - Can you please post the hw detection log?

[Brian_Oblivion 4]

I just grabbed the 1st one I could find. Hope it helps. 

hardware_detection-63899887128.txt

[softworkz 5066]

Thanks for the log!

The detection is actually getting correct results. In your case, it doesn't show any profiles for VC-1:

 

 

This is from another user (Alder Lake) which shows it's supported:

 

So, it's not that it has been dropped in the drivers, it's just not implemented for your GPU.

 

Still, the fault is on our side: Will need to investigate why its still being shown as supported in your case.

 

[Brian_Oblivion 4]

Hmmm...  If it matters, this is running in a docker container with a Intel CPU - thus there's an onboard GPU in the CPU in addition to the A380 card I have in it.

This is what my config screen looks like,  all of them are the same except the odd duck of the VC-1. Not entirely sure why they are "duplicated" other than the VAAPI driver is excluding VC-1 (as it should since it's no longer supported). 

 

Edited December 1, 2025 by Brian_Oblivion

[softworkz 5066]

Sorry, I've been mistaken - it's been a few years since it was implemented. So, no profiles being shown does NOT mean that the  codec is unsupported. When a codec is unsupported then it isn't shown at all. An analysis of detection logs which were sent by users during the past few years, shown that it happens quite often that the profiles are not present, even though the codec is supported:

 

This aligns with the implementation we have in the server: it doesn't sort out based on missing profiles, just on whether an entry exists or not.

Over all the years, I don't remember a single case where the hardware detection was wrong - this would be the very first case. It's possible for sure, because it's a combination of "rarely use GPU" and "rarely used codec" - which multiplies down to "extremely rare". 

But I'm curious how it fails exactly. Can you post an ffmpeg log from a failed transcoding with VC-1?

Thanks

[Brian_Oblivion 4]

Basically it fails to stream it at all. ffmpeg tries to use the gpu and blows up over and over because it doesn't support VC-1.

Attached is the log file with all the gory details

Also, I believe VC-1 isn't all that uncommon - esp in older DVDs (which this is a rip from). 

 

ffmpeg-transcode-f2687bf9-e2fb-4daa-be03-97f2af5656bf_1.txt

Edited December 2, 2025 by Brian_Oblivion

[softworkz 5066]

Thanks for the log, that's interesting.. Possibly the VC1 implementation hasn't been updated to use the memory abstractions in order to deal with discrete GPU variants (which do not have shared memory). That's what the error appears to indicate, because when the codec wouldn't be supported it would have failed earlier already.

Essentially though, we do not really now what we're dealing with. I wouldn't even know a basis for making any automatic adjustments. 
I think for the moment, all we can do is to observe this and see whether other reports about this would surface and maybe then we will recognize a pattern. We revisit this topic anyway in the near future, then we might get an understanding (or maybe this is just a weird one-off quirk).

Anyway, thanks a lot for reporting!