Fix crash due nullptr surface using DXVA2

[fritsch]

This may happen when a stream starts with non I frame.

Follow-Up of: #24058

Reasoning:
Kodi will release Omega with version 6.0.1
6.0.1 for sure won't get this fix upstream, therefore we include it as shown here for windows (it's dxva2 anyways) only
Latest when bumping to the next ffmpeg version in Omega+1, we send the patch upstream again
Any input welcome with the focus on working user experience, means: What can we do so that Windows users can enjoy, especially LiveTV without crashes.

[CrystalP]

Builds and works as expected, thank you!

[CrystalP]

Was there a reason for merge/reversal in ffmpeg?
The alternative of starting playback on an I frame doesn't sound bad, but maybe adds unreasonable delays for some streams? More risky at this stage of the release cycle.
How would one check the type of the first frame in the samples?

edit: actually can we even get a valid decoded picture until an I frame is reached?

[fritsch]

Patch was forwarded by @garbear - Thank you very much!

jenkins build this please

[thexai]

How would one check the type of the first frame in the samples?

With VirtualDub:

First frame is type P = predicted picture

Fist key frame (I frame) is num 348 in this sample. VirtualDub uses [K] notation.

Anyway video is playable from first frame.

Note that P-frame definition is:

"P‑frames can use data from previous frames to decompress and are more compressible than I‑frames."

and not

"P‑frames must use data from previous frames to decompress and are more compressible than I‑frames."

Then probably in this sample first frame is signaled/flagged as type P but not uses data of previous frames and then can be used as key (I) frame.

[lrusak]

Can you link the relevant ffmpeg mailing list discussion please?

[fritsch]

@lrusak seems team Kodi colleagues agreed on a different path with the VLC ffmpeg people. I thought this is an alignment.

If it's not enough, I can post it on the ML. But I did not want to interfer with agreed best practices when I did not take part.

@garbear is this patch cooperation somewhere documented?

[garbear]

The documentation is called buy a plane ticket to VDD and hunt down ffmpeg devs until you find someone familiar with the code 🙂 as of now it's largely a one-way email thread that has mostly gone unanswered. Here's the list of patches we're trying to get eyes on:

https://github.com/xbmc/FFmpeg/commits/release/5.1-kodi

• No slices h264: xbmc/FFmpeg@ca8882f

• Git built in sub folder: xbmc/FFmpeg@43ad570

And now this one:

• 0687ea6 - Samples that can be found here: [Windows][FFmpeg] Fix crash due nullptr surface using DXVA2 #24058 (comment)

[fritsch]

Thanks @garbear if there is sth I should do towards this upstreaming, do not hesitate to tell me. For the time in between I consider it as all fine.

Thanks very much.