[Bug]: FFmpeg (master) transcoding fails with latest media-driver (master) about media-driver HOT 10 OPEN

@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)

from media-driver.

@xhaihao have you seen this issue?

from media-driver.

@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

from media-driver.

@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).

from media-driver.

@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.

from media-driver.

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.

from media-driver.

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.

from media-driver.

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

from media-driver.

Auto Created VSMGWL-72133 for further analysis.

from media-driver.

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!

from media-driver.