Fix AV1/VP9 (and send/receive API use in general)

[dwbuiten]

This PR does two things:

• Properly sets the delay when AV1 is being decoded, which is possible since FFmpeg/FFmpeg@1b05d27. We can make this slightly more generic to all codecs, but I want to change that later in a separate change set so as to keep any introduced bugs separate.
• Properly handles AVERROR(EAGAIN) from avcodec_send_packet by stashing the packet to send again on the next call, and from avcodec_receive_frame by increasing the delay counter.

Since this makes changes to the core decode loop(s), it needs some good testing before merging. Particularily to confiirm AV1 and VP9 are, in fact, fixed (seeking, and linear).

Should (probably) fix #319, and makes #323 obsolete, I think. May or may not fix #352.

CC: @tdaede @jamrial @wangqr

[myrsloik]

Looks reasonable, will try on some random av1 files later

[tdaede]

If we can delay more than once, shouldn't the stashed packet be a stash queue?

[dwbuiten]

No, since we don't read another packet until the stashed one is successfully sent.

[CoffeeFlux]

Anything I can do to help move this along? I'm looking at getting a new Aegisub stable out but I'd like to have proper VP9/AV1 support, and don't want to build against a fork.

[dwbuiten]

Anything I can do to help move this along? I'm looking at getting a new Aegisub stable out but I'd like to have proper VP9/AV1 support, and don't want to build against a fork.

Mostly it is a function of my time (of which I have little at the moment...) - the current PR seems to have issues, which I need to debug.

[L4cache]

How about using libvpx to decode vp9? It seems more multi-thread capable than native one (but maybe slightly slower in single-thread) and with support of alpha channel in addition.

It seems not suffer form #352. Let me list in detail:

1. ffms2 current HEAD, ffmpeg branch release/6.1, native vp9 decoder: broken
2. ffms2 current HEAD, ffmpeg branch release/6.1, libvpx decoder: good
3. ffms2 , ffmpeg branch release/6.1, native vp9 decoder: looks ok with regularly skipped(duplicated) frames
4. ffms2 , ffmpeg branch release/6.1, libvpx decoder: good
5. ffms2 tag 2.40, ffmpeg branch release/4.3, native vp9 decoder: broken
6. ffms2 tag 2.40, ffmpeg branch release/4.3, libvpx decoder: looks ok but frame count and fps are off
7. This PR, ffmpeg branch release/6.1, native vp9 decoder: good
8. This PR, ffmpeg branch release/6.1, libvpx decoder: good

All above are built with msys2 mingw-w64 (as used by media-autobuild_suite), decoded data from all "good" results are exactly the same

[L4cache]

I encountered this error opening files with video+audio with several combination of codecs after this PR.
vapoursynth.Error: Source: Insanity detected: decoder returned an empty frame

But not all file of problematic combination will cause error, for example vp9+opus produced by ffmpeg fails but some files downloaded from YouTube don't.
If audio is removed then the decoding will be successful.

[dwbuiten]

@L4cache I am revisiting this PR currently, can you provide an example file?

[L4cache]

@L4cache I am revisiting this PR currently, can you provide an example file?

https://transfer.sh/85oyj7LBrm/sample.zip

I forgot to mention, the way I apply this pr is https://github.com/L4cache/ffms2/tree/test-3
Many more video+audio codec combinations are affected, like, basically anything but h264 or h265 + commonly used lossy audio encoders (libmp3lame is broken but libshine is ok so I say encoder)

[dwbuiten]

@L4cache Thanks, I was able to reproduce the issue using your sample. I will look into it.

[dwbuiten]

@L4cache I found the bug. I have updated the PR.

[dwbuiten]

Merged, let the testing begin!

Note thay CI failed for unrelated reasons. Tests pass locally, aside from HDR metadata which is being fixed upstream in FFmpeg right now.