CDVDVideoCodecDRMPRIME: Fix use of v4l2request hwdevice

[Kwiboo]

Description

This PR extend CDVDVideoCodecDRMPRIME to support using any AVCodecHWConfig that support drm_prime output.

~Created as a draft PR because work-in-progress FFmpeg patches are still being worked on.~

The reworked v2 patches was posted in early August, a v3 series with minimal changes should reach ffmpeg-devel next few days.

Motivation and context

Current out-of-tree FFmpeg V4L2 Request API hwaccel patches abuse the drm hwdevice type.

Revised v2 patches posted for upstream FFmpeg changed this to use a new dedicated v4l2request hwdevice type.

Use of device ? device : "(null)" to work around string pointer is null exception from libfmt when a nullptr device was being logged.

How has this been tested?

Using work-in-progress FFmpeg patches on a LibreELEC based image.

What is the effect on users?

None, users can use both old out-of-tree FFmpeg V4L2 Request API hwaccel patches or newer reworked patches for upstream FFmpeg.

Screenshots (if appropriate):

Types of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] Clean up (non-breaking change which removes non-working, unmaintained functionality)
• [x] Improvement (non-breaking change which improves existing functionality)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that will cause existing functionality to change)
• [ ] Cosmetic change (non-breaking change that doesn't touch code)
• [ ] Student submission (PR was done for educational purposes and will be treated as such)
• [ ] None of the above (please explain below)

Checklist:

• [x] My code follows the Code Guidelines of this project
• [ ] My change requires a change to the documentation, either Doxygen or wiki
• [ ] I have updated the documentation accordingly
• [x] I have read the Contributing document
• [ ] I have added tests to cover my change
• [ ] All new and existing tests passed

[jernejsk]

This looks good to me and imo it could be merged regardless of ffmpeg patches state. People can invent their own ffmpeg extensions...

[Kwiboo]

This looks good to me and imo it could be merged regardless of ffmpeg patches state. People can invent their own ffmpeg extensions...

Agree, changes in this PR should be fine regardless of patches for FFmpeg, have removed the draft status of this PR.

[popcornmix]

I added this to my local build over the weekend on a Pi5. Seemed fine.