VideoPlayer glitch when video ends with identical frames

[ocdmonkey]

Godot version:
3.0.6

OS/device including version:
Windows 10 Home

Issue description:

https://www.youtube.com/watch?v=gs2L_lzKJQ8&feature=youtu.be

Basically, it seems that if a video ends with a bunch of identical frames it just completely glitches out. That video was shot using Godot 3.0.2 and using a VP9 encoded video, but I have since tested it with 3.0.6 and it is still present. I've tested this with Theora and VP9 videos, and the main difference is that Theora correctly continues the stream_position variable to the end, but the audio still glitches out. I have also confirmed this happening with another video from Riven.

I straight up could not get videos converted with FFMPEG to work with Godot (Theora would be blue shifted, VP9 would just mess all the colors up), so I suppose it could be an encoding issue, but since the symptoms are almost identical between the codecs I suspect it's an issue with videoplayer.

Steps to reproduce:
Get a video with a bunch of identical frames at the end, and put it in a Videoplayer node.

Minimal reproduction project:
videoplayer bug.zip

[tom-jk]

Testing MRP on linux mint 18.3.
Tested the WebM and can reproduce in all versions tested: 3.0.6, 3.1, 3.2, 3.2.2, 3.2.3.beta1.
Tested the OGV and can reproduce in all versions tested: 3.0.6 and 3.2.3.beta1.

Printed stream_position runs smoothly for OGV while stopping/skipping for WebM, as observed above.

tests with other software

Can also reproduce with the WebM (but not the OGV) in VLC Media Player 2.2.2 (WebM sound skips/stutters at end like Godot; OGV has choppy frame rate throughout but does complete).

Can't reproduce in XPlayer 1.6.1 for either format (music plays through; no apparent issue with visuals).
Can't reproduce in Firefox 76.0 for either format.

note: VLC and XPlayer recognises the WebM as VP8 rather than VP9.

Ideally someone would produce a couple short (~10-20sec) videos - one with a sustained end frame and continuing audio, and another with frames and audio to the end - to test whether it does have anything to do with a video/audio length mismatch as hypothesised above.

@ocdmonkey would you still be interested in testing this issue?

[DeeJayLSP]

note: VLC and XPlayer recognises the WebM as VP8 rather than VP9.

That's because it is VP8.

so I suppose it could be an encoding issue

I got some warnings while trying to reencode, so I suppose it's indeed an encoding issue.

[DeeJayLSP]

I ran some reencoding tests on FFmpeg.

WebM's case

First, the original WebM was converted to FFV1 + FLAC, then encoded back to VP8 + Vorbis. The problem remained.

Then, I tried again by converting it to H.264 + AAC, then back. This one however played normally.

We should conclude that, at least for WebM, it was just an encoding issue.

Theora's case

I was unable to make the .ogv work properly on acceptable settings. Even tried extracting all the frames and putting them back.

However, there was one setting that worked properly: when the keyframe interval was set to 1.

The problem is, a video with a keyframe interval at 1 means it will have about 10 times its usual size.

I tried with different keyframe settings. The higher it is set, the buggier becomes the audio.

I went back to the WebM one and tried to set a high keyframe interval, but the bug didn't reappear.

Considering how the issue remained when using FFV1 between the reencodings, I'm assuming the WebM supplied in the reproduction project was converted from the .ogv.

May we consider it's a Theora issue now?

[akien-mga]

Consolidating in #66331 which is about the same underlying bug.