testffmpeg default (gles EGL) fails
using the default selected renderer with testffmpeg, output fails.
manually disabling with SDL_VIDEO_FORCE_EGL=0 works
es2gears_x11, eglgears_x11, xeglgears, and glxgears from https://gitlab.freedesktop.org/mesa/demos/-/tree/main all run without issue
INFO: Created renderer: opengles2
INFO: Created renderer opengles2
INFO: Video stream: vp9 3840x2160
Opening in BLOCKING MODE
INFO: ffmpeg verbose: Old NvBuffer Utils version
NvMMLiteOpen : Block : BlockType = 280
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 280
INFO: ffmpeg verbose: Starting capture thread
INFO: ffmpeg verbose: Resolution changed to: 3840x2160
INFO: ffmpeg verbose: Colorspace ITU-R BT.601 with standard range luma (16-235)
INFO: ffmpeg verbose: Query and set capture successful
INFO: ffmpeg verbose: Resource unavailable!
INFO: ffmpeg verbose: Resource unavailable!
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
DEBUG: unable to show color buffer in an OS-native window (call to eglSwapBuffers failed, reporting an error of EGL_BAD_CONTEXT)
`.:/ossyyyysso/:. gman@gman-nob
.:oyyyyyyyyyyyyyyyyyyo:` -------------
-oyyyyyyyodMMyyyyyyyysyyyyo- OS: Kubuntu noble 24.04 aarch64
-syyyyyyyyyydMMyoyyyydmMMyyyyys- Host: Nintendo Switch (2017)
oyyysdMysyyyydMMMMMMMMMMMMMyyyyyyyo Kernel: Linux 4.9.140-l4t
`oyyyydMMMMysyysoooooodMMMMyyyyyyyyyo` Uptime: 14 hours, 19 mins
oyyyyyydMMMMyyyyyyyyyyyysdMMysssssyyyo Packages: 3085 (dpkg), 2 (flatpak)
-yyyyyyyydMysyyyyyyyyyyyyyysdMMMMMysyyy- Shell: bash 5.2.21
oyyyysoodMyyyyyyyyyyyyyyyyyyydMMMMysyyyo Display (DELL ST2220L): 1920x1080 @ 60 Hz in 22″ [External]
yyysdMMMMMyyyyyyyyyyyyyyyyyyysosyyyyyyyy DE: KDE Plasma 5.27.11
yyysdMMMMMyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy WM: KWin (X11)
oyyyyysosdyyyyyyyyyyyyyyyyyyydMMMMysyyyo WM Theme: plastik
-yyyyyyyydMysyyyyyyyyyyyyyysdMMMMMysyyy- Theme: Breeze (Dark) [Qt], Breeze [GTK2/3/4]
oyyyyyydMMMysyyyyyyyyyyysdMMyoyyyoyyyo Icons: breeze-dark [Qt], breeze-dark [GTK2/3/4]
`oyyyydMMMysyyyoooooodMMMMyoyyyyyyyyo Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4]
oyyysyyoyyyysdMMMMMMMMMMMyyyyyyyyo Cursor: breeze (24px)
-syyyyyyyyydMMMysyyydMMMysyyyys- Terminal: konsole 23.8.5
-oyyyyyyydMMyyyyyyysosyyyyo- CPU: ARMv8 rev 1 (v8l) (4) @ 2.09 GHz
./oyyyyyyyyyyyyyyyyyyo/. GPU: NVIDIA Tegra X1 (nvgpu) [Integrated]
`.:/oosyyyysso/:.` Memory: 2.22 GiB / 3.90 GiB (57%)
Swap: 433.66 MiB / 3.00 GiB (14%)
Disk (/): 50.01 GiB / 122.94 GiB (41%) - ext4
Disk (/media/gman/SWITCH SD): 54.51 GiB / 69.98 GiB (78%) - vfat
Disk (/media/gman/SWR-JAM): 99.48 GiB / 122.92 GiB (81%) - ext4
Disk (/media/gman/Universal): 39.83 GiB / 66.39 GiB (60%) - ext4
Local IP (enxa0cec8b7dc74): 10.0.0.195/24
Battery: 100% [AC Connected]
Locale: en_US.UTF-8
I can't reproduce this here, does it fail the same way for the other SDL test programs, e.g. testsprite?
No response, I'll go ahead and close this for now. Please let us know if it's still an issue.
@slouken sorry for the delay. testdraw and testsprite have no issues but I believe this is because they are using the Vulkan render. testgles2, testgl also work. So seems like an issue unique to the EGL implementation that I guess none of the other tests implement or use.
testsprite --renderer opengles2 should have the same codepath as testffmpeg?
testsprite --renderer opengles2should have the same codepath as testffmpeg?
No issues with that. Can confirm that is actually using opengles2 so the options are working. It doesn't seem like the same EGL path is being used in these other tests.
Okay, well please let us know if you find out what's different about testffmpeg.
The whole thing (https://github.com/libsdl-org/SDL/blob/bf54eddba964a9d27723c9d958ff889f1fcf4a89/test/testffmpeg.c#L109-L135) is different from the other tests. I don't understand why testffmpeg is its own thing and doesn't use SDL_test_common.c as a base like all the other tests. I don't see why you are implementing stuff differently here.