[Bug]: FFmpeg (master) transcoding fails with latest media-driver (master)

[eero-t]

Which component impacted?

Decode

Is it regression? Good in old configuration?

Yes, it's good in old version

What happened?

This is more likely to be FFmpeg regression than media-driver one, but as media-driver had few commits also between good and bad versions, I'm filing the issue here too.

For details, see the FFmpeg bug: https://trac.ffmpeg.org/ticket/10856

(If that issue is indeed FFmpeg one, please close this one.)

What's the usage scenario when you are seeing the problem?

Transcode for media delivery

What impacted?

No response

Debug Information

No response

Do you want to contribute a patch to fix the issue?

No.

[Sherry-Lin]

@xhaihao have you seen this issue?

[xhaihao]

@eero-t It should be caused by the change in FFmpeg. Could you try with https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9639 ? (Note for FFmpeg QSV, you should use configuration option --enable-libvpl instead of --enable-libmfx to build FFmpeg, this patchset works for TGL+ devices and libvpl GPU runtime)

[xhaihao]

@eero-t You may use https://github.com/intel/cartwheel-ffmpeg directly if you fail to apply https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9639

[eero-t]

@xhaihao Thanks! While I have another test set for checking oneVPL based FFmpeg (upstream release) builds on dGPUs, this particular test set is for checking FFmpeg upstream HEAD with (media-driver +) VA-API & old MFX backends, on (older) iGPUs (ones fully supported by libMFX).

(I've thought to switch latter test setup to oneVPL only when FFmpeg finally drops --enable-libmfx configure option.)

@eero-t You may use https://github.com/intel/cartwheel-ffmpeg directly if you fail to apply https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9639

Series seems to need an update as it does not apply to FFmpeg HEAD:

ffmpeg: Apply patch 0-https___patchwork_ffmpeg_org_series_9639_mbox_
+ patch -p1 -d builder/source0/ffmpeg
patching file doc/APIchanges
Hunk #1 FAILED at 2.
1 out of 1 hunk FAILED -- saving rejects to file doc/APIchanges.rej
patching file libavutil/hwcontext_qsv.c
patching file libavutil/hwcontext_qsv.h
patching file libavutil/version.h
Hunk #1 FAILED at 79.
1 out of 1 hunk FAILED -- saving rejects to file libavutil/version.h.rej
patching file libavutil/hwcontext_qsv.c
patching file libavutil/hwcontext_qsv.c
patching file libavutil/hwcontext_qsv.c
patching file libavcodec/qsv.c
patching file libavcodec/qsv.c
patching file libavcodec/qsvenc.c
Hunk #1 succeeded at 718 (offset 1 line).
Hunk #2 succeeded at 843 (offset 1 line).
patching file libavcodec/qsv.c
patching file libavcodec/qsvdec.c
patching file libavfilter/qsvvpp.c
patching file libavfilter/qsvvpp.c
patching file doc/APIchanges
Hunk #1 FAILED at 2.
1 out of 1 hunk FAILED -- saving rejects to file doc/APIchanges.rej
patching file libavutil/hwcontext_vaapi.c
patching file libavutil/hwcontext_vaapi.h
patching file libavutil/version.h
Hunk #1 FAILED at 79.
1 out of 1 hunk FAILED -- saving rejects to file libavutil/version.h.rej
patching file libavcodec/vaapi_decode.c
Hunk #1 succeeded at 601 (offset 1 line).
patching file libavfilter/vaapi_vpp.c
Hunk #1 succeeded at 203 (offset 4 lines).

[xhaihao]

@xhaihao Thanks! While I have another test set for checking oneVPL based FFmpeg (upstream release) builds on dGPUs, this particular test set is for checking FFmpeg upstream HEAD with (media-driver +) VA-API & old MFX backends, on (older) iGPUs (ones fully supported by libMFX).

MediaSDK runtime doesn't support delayed allocation in decoding, so https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9639 doesn't work with old MFX backends. (vaapi path in FFmpeg should work).

(I've thought to switch latter test setup to oneVPL only when FFmpeg finally drops --enable-libmfx configure option.)

@eero-t You may use https://github.com/intel/cartwheel-ffmpeg directly if you fail to apply https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9639

Series seems to need an update as it does not apply to FFmpeg HEAD:

ffmpeg: Apply patch 0-https___patchwork_ffmpeg_org_series_9639_mbox_
+ patch -p1 -d builder/source0/ffmpeg
patching file doc/APIchanges
Hunk #1 FAILED at 2.
1 out of 1 hunk FAILED -- saving rejects to file doc/APIchanges.rej

See https://github.com/intel/cartwheel-ffmpeg?tab=readme-ov-file#apply-patches for information about applying patch.

[eero-t]

MediaSDK runtime doesn't support delayed allocation in decoding, so https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9639 doesn't work with old MFX backends. (vaapi path in FFmpeg should work).

Ok. As the MediaSDK backend is not in working shape any more in upstream FFmpeg HEAD, and MediaSDK project itself is not maintained any more, is MediaSDK support going to be dropped from upstream FFmpeg along with that fix series?

Btw. I remember that while oneVPL can use MediaSDK as a backend (for older platforms), it did not have support for all of its niche features originally. Has support for those few items been added to oneAPI by now, or are there still valid arguments for objections on dropping direct MediaSDK support from upstream FFmpeg?

(I do not myself care about those niche features, so I'm fine with switching to oneVPL backend, I'm just curious about when I need to do that, and whether others could still object to such change.)

See https://github.com/intel/cartwheel-ffmpeg?tab=readme-ov-file#apply-patches for information about applying patch.

Thanks, but this bug is only about whether upstream FFmpeg works.

[xhaihao]

Thanks, but this bug is only about whether upstream FFmpeg works.

The upstream FFmpeg was added as a submodule in https://github.com/intel/cartwheel-ffmpeg and it is updated every day.

[xhaihao]

@eero-t could you try with another patch intel-media-ci/ffmpeg#709 ?

[intel-mediadev]

Auto Created VSMGWL-72133 for further analysis.

[eero-t]

Sorry for the late reply.

@eero-t could you try with another patch intel-media-ci/ffmpeg#709 ?

@xhaihao Thanks, that one applies to latest upstream, and does fix the FFmpeg failures!