Support for VP9 decoding with Apple's VideoToolbox

[colincornaby]

This PR adds VideoToolbox support alongside the exist libwebm support. It can optionally replace the libvpx decoder. This decoder is only available on Apple devices that feature hardware decoding support - Apple does not include a software decoder and this code will fallback to libvpx in that case. Apple has not provided hardware decoding drivers for all hardware that could support it - this functionality seems mostly limited to Apple Silicon devices.

For other platforms like iOS and visionOS where hardware decode support is guaranteed - this turns libvpx into an optional dependency. This is especially helpful for visionOS where there are no working builds of libvpx.

[colincornaby]

Tried to be sensitive here in since I know this code is already earmarked for a refactor. Basic abstraction to keep plMoviePlayer away for decoder specifics.

[colincornaby]

This ISO doc is paywall so I can't link to it. However WebKit implements the atom that needs to be passed to the decoder in the same way with the same structure. The WebM documentation is public and assumes you know what a "full box" is.

[colincornaby]

Two things:
The VTDecompressionSessionDecodeFrameWithOutputHandler is a monster but I'm not sure how to break it up because it includes a function block. It might be Stockholm syndrome in since Apple developers tend to be used to the long lines and verbose API.

I am extremely rarely hitting this during the intro movie:

ASSERTION FAILED:
File: /Users/colincornaby/Documents/Plasma/PlasmaSrc/Sources/Plasma/FeatureLib/pfMoviePlayer/plMoviePlayer.cpp Line: 163
Message: Failed to decode tile data

This is odd because this is the layer between libwebm and libvpx - which I didn't touch. The Mac Pro I'm testing this on doesn't activate the VideoToolbox path either (hardware isn't compatible.) I'm checking into it. Address Sanitizer is not finding any memory corruption issues.

[colincornaby]

The crash may be unrelated - it seems to happen when I spam input just as the movie is starting. Clicking on the window just right before the intro movie plays seems to do it.

I'll continue investigating before asking this PR to be merged just in case...

[dgelessus]

A while ago I encountered a different crash when spamming Esc to skip the intro (fixed in #1718). That was in a completely different part of the code than your assertion failure, so I assume the two aren't related, but perhaps plMoviePlayer has a similar logic issue if it receives multiple "stop requests" at (almost) the same time?

[colincornaby]

It's not clear to me. I can see the decoder provides a compressed frame that is under 100 bytes which seems... small. Although maybe the first frame fits. codec has a VPX_CODEC_CORRUPT_FRAME error state.

Nothing in the path seems input triggered to me right now. It's the normal decode loop. Trying to see how input could influence things...

[colincornaby]

I fixed the issue - it was introduced by this branch. The problem was here:

for (const auto& frame : frames) {
    const std::unique_ptr<uint8_t>& buf = std::get<0>(frame);
    uint32_t size = static_cast<uint32_t>(std::get<1>(frame));
#ifdef USE_VIDEOTOOLBOX
    if (!img && fVt)
        img = fVt->DecodeNextFrame(buf.get(), size);
#endif
#ifdef USE_VPX
    if (!img && fVpx)
        img = fVpx->Decode(buf.get(), size);
#endif
}

If multiple frames were processed by the loop (because the computer was slow or I was spamming input making things slow) decode would fail because img would be populated and it would skip subsequent decodes. These gaps would cause future decodes to fail until the next keyframe.

This has been fixed in the latest commit.

[Hoikas]

Just two very minor things left, I think.

[colincornaby]

I added a check to the VT path as well. That one is a bit different because I specifically request the output format. It might automatically transcode to the right format - but otherwise I added a check for a null output.

Repeating the offer from chat to squash this down so no one has to bisect through all these changes.