VideoPlayer playback smoothness regression in Godot 3.4 on some hardware

[hhyyrylainen]

Godot version

v3.4.stable.mono.official.206ba70f4

System information

Windows 10, GLES3, AMD Radeon R7 250 Series

Issue description

I got reports and noticed on my laptop that after the move to Godot 3.4 our game's intro video plays really choppy / lags. The audio also has issues and it seems towards the end, of the few seconds long video, it gets even worse seemingly freezing for like half a second. Stopping the video immediately manages to skip it.
I'm relatively confident that this is a Godot 3.4 regression as we haven't changed our video playing interacting code at all, but we updated our used Godot version to 3.4.

Also a problem with NVIDIA GeForce 940MX, and I haven't heard from the third user yet. I kind of suspect that lower CPU performance is the common factor here.

Update: third user has:

Godot Engine v3.4.stable.mono.official.206ba70f4 - https://godotengine.org
OpenGL ES 3.0 Renderer: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2
OpenGL ES Batching: ON

Second update: I just tested on Fedora 34 on my laptop and the problem doesn't occur there. So maybe this is a Windows specific issue.

Steps to reproduce

Try to play the following video with a fullscreen Godot VideoPlayer in a project: https://dev.revolutionarygamesstudio.com/api/v1/download_lfs?project=2&path=%2Fassets%2Fvideos&name=intro.webm

We have a second video which plays a bit better but also lags a bit towards the end. It's probably a bit lower in bitrate, which might be sort of the cause behind the choppy playback, however earlier Godot versions played the exact same file just fine even on my lower power laptop.

Minimal reproduction project

No response

[Calinou]

@hhyyrylainen Can you reproduce this in any of the 3.4 betas and RCs to determine when the regression started?

[hhyyrylainen]

I can try. I already did a bit of further testing and found out that when I boot up Linux on my laptop the video runs without stuttering, so perhaps this is a Windows only issue. At least on my laptop only Windows 10 shows the issue, so this might not be a CPU power related thing.
I can give the betas and RCs a try tomorrow to see which ones work (I'll skip the versions that are unable to run the game due to code incompatibility as we needed to slightly adjust our C# source code when upgrading to 3.4).

[hhyyrylainen]

Here's the results from that:

• beta 1: doesn't run:
  Failed to deserialize settings file data, data may be improperly formatted. Using default settings instead.
  Error initializing global settings: System.TypeInitializationException: The type initializer for 'System.ComponentModel.TypeDescriptor' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Sys' threw an exception. ---> System.DllNotFoundException: System.Native assembly: type: member:(null)
  at (wrapper managed-to-native) Interop+Sys.LChflagsCanSetHiddenFlag()
  at Interop+Sys..cctor () [0x00000] in <2606d1e3191f45969af1cc6149da86d0>:0
  --- End of inner exception stack trace ---
• beta 2: game starts but crashes while showing the loading logo:
  ERROR: Condition "array.size() != array_size" is true.
  at: mesh_add_surface (drivers/gles3/rasterizer_storage_gles3.cpp:3554)
  ERROR: Index p_surface = 0 is out of bounds (mesh->surfaces.size() = 0).
  at: mesh_surface_set_material (drivers/gles3/rasterizer_storage_gles3.cpp:3845)
  ERROR: Expected data size of 49916 bytes in Image::create(), got instead 49915 bytes.
  at: (core/image.cpp:1773)
  ERROR: Condition "!read.ptr()" is true.
  at: texture_set_data (drivers/gles3/rasterizer_storage_gles3.cpp:757)
  ERROR: Expected data size of 49916 bytes in Image::create(), got instead 49915 bytes.
  at: (core/image.cpp:1773)
  ERROR: Condition "!read.ptr()" is true.
  ERROR: at: Expected data size of 113468 bytes in Image::create(), got instead 113467 bytes.
  texture_set_data (drivers/gles3/rasterizer_storage_gles3.cpp:757)
  at: (core/image.cpp:1773)
  ERROR: Condition "!read.ptr()" is true.
  at: texture_set_data (drivers/gles3/rasterizer_storage_gles3.cpp:757)
  ERROR: Expected data size of 49916 bytes in Image::create(), got instead 49915 bytes.
  at: (core/image.cpp:1773)
  ERROR: Condition "!read.ptr()" is true.
  at: texture_set_data (drivers/gles3/rasterizer_storage_gles3.cpp:757)
  ERROR: Expected data size of 49916 bytes in Image::create(), got instead 49915 bytes.
  at: (core/image.cpp:1773)
  ERROR: Condition "!read.ptr()" is true.
  at: texture_set_data (drivers/gles3/rasterizer_storage_gles3.cpp:757)
• beta 3: laggy video
• beta 5: laggy video

[akien-mga]

See #53959 and #50862, this is probably because 3.4 was built without YASM optimizations on Windows, due to them causing crashes with some WebM videos.

The above PR was merged after 3.4 beta 3, but earlier builds were already made without having yasm installed in the build environment, so the effect is the same.

I would advise trying the Theora decoder instead of WebM, as the latter is too buggy (and was removed in Godot 4.0: #53833).
Another option is to use https://github.com/kidrigger/godot-videodecoder to have access to more video codecs with a better maintained implementation.

Alternatively, you could do a custom build with YASM but you'd have to revert #53959 locally.

[hhyyrylainen]

For now I converted our videos to the theora format (as that now seems to be the only supported one by Godot?), and one person reported that the video lag went away with that change.

[akien-mga]

I'll close as there's no plan in the near future to improve the WebM decoder and to re-enable the crashy YASM optimizations on Windows - and the WebM support was removed in 4.0 (for now - a GDExtension might provide better video support with e.g. ffmpeg in the future). Of course if someone wants to work on these issues we can definitely review and merge fixes.