Trying to reencode for the Pi2 to be able to handle: for i in *.*; do ffmpeg -i "$i" -c:v mpeg2video -qscale:v 1 "../1080p-mpeg2/${i%.*}.mpg"; done

It does handle things better, but still not well, hmm. Perhaps 1080p playback is beyond it, or perhaps I'm just doing it too inefficiently. Swapping the card into a Pi 3, though, and it's fine.

EDIT: okay nearly fine . . .

EDIT THE SECOND: Hmm I wonder if it's drawing on top of each instance and that's making it slower each time? It kinda looks like that, come to think of it.

Hitting the key a bazillion times didn't make it any slower, so it's just rendering generally slow I guess. I might need to work out a more efficient way using the hardware decode of the Pi3 or such . . .

Curious if this can be made to run on random Android tablets, which would instantly make useful a bunch of spare hardware I have. It seems like it should be possible, via https://github.com/kivy/python-for-android/ and https://buildozer.readthedocs.io/en/latest/, though once again my use of opencv and its sprawling requirements may pose a problem.

Testing powering my Pi3, a USB one-key keyboard, and an entire 1080p 13" OLED display just off of my big but old USB battery pack, and over an hour later it's still showing 4/4 battery level LEDs, so so far so good in terms of power consumption.

Just noticed it died, lets say about 19:00 to 28:00 then for 9hrs on just this portable USB battery pack, certainly couldn't power it on its own for the full weekend then but that ain't bad.

Hmmm a note in https://forums.raspberrypi.com/viewtopic.php?t=244975 (which I haven't yet read all of) implies that perhaps I need the color profile set to BGR in the videos to avoid costly CPU decoding, maybe that'll do the trick?

https://www.pygame.org/docs/ref/image.html#pygame.image.frombuffer lists only a few pixel formats that can be used, basically all just RGB variations.

Looking to https://trac.ffmpeg.org/wiki/colorspace and https://stackoverflow.com/a/12573365/2808933 for incantations to use. Maybe this will spit out some MPEG2 videos that can be blitted fast enough?

for i in *.*; do ffmpeg -y -i "$i" -c:v mpeg2video -qscale:v 1 -pix_fmt bgr24 "../1080p-mpeg2/${i%.*}.mpg"; done

Incompatible pixel format 'bgr24' for codec 'mpeg2video', auto-selecting format 'yuv420p'

Having a hard time finding any reasonable list of such formats. https://gist.github.com/antoineMoPa/75607631fb477a87d73d5733589e420a doesn't look like the formats in the right naming convention and fails to list video formats they work for which is what I clearly really need.

Lets try this then: for i in *.*; do ffmpeg -y -an -i "$i" -c:v libx264rgb -crf 5 -pix_fmt bgr24 "../1080p-testing/${i%.*}.mkv"; done (insanely high CRF but we really don't care too much about filesize yet; -an to have no audio)

and . . . frankly if anything that made it worse.

Tried to force hardware acceleration along the lines of https://forum.opencv.org/t/how-to-get-faster-lighter-video-decoding/5250 with stuff like

cap = cv2.VideoCapture(video,
                apiPreference=cv2.CAP_FFMPEG,
                params=[
                        cv2.CAP_PROP_HW_ACCELERATION, cv2.VIDEO_ACCELERATION_ANY,
                    ])

but no change, still 3+ cores of CPU used and slow framerate.

Maybe I need to abandon OpenCV and skip back to trying to use FFMPEG directly, a la https://stackoverflow.com/a/62870947 ?

Also bad is that when going so slowly, releasing the key doesn't always actually trigger a new video, though I can just have the blank loop check and run the video loop if it sees no key is currently being pressed. For now I actually kinda like that behaviour because it lets me confirm that CPU load drops down to very very low while in the blank loop.

Got back at this, decided to try to run just direct invocations of video players that have hardware decode on the Pi.

MPV?

My first port of call was mpv, which is expressly a commandline video player without a GUI. Perfect for the GUI never showing up! Unfortunately the video playback was jerky and incredibly glitchy (like, mirror-mapped along a diagonal levels of glitchy), so that would probably take some work.

VLC?

Second try vlc. Alllllllmost perfect with this:
vlc --fullscreen --loop --no-mouse-events --no-keyboard-events --video-on-top --no-osd --mouse-hide-timeout=1

It's certainly much much smoother! Unfortunately it pauses for a split second when the video loops, which I can reproduce on my desktop system where the videos loop fine with my pygame-based implementation of this. I briefly turned to the wilderness of the internet to see if this was common or fixable; as per usual the best Reddit can do is confirm other people also have a problem and never actually provide any solution (I suppose it's possible that for normal people they find solutions to problems on Reddit, but apparently my own problems are always esoteric enough that I have literally yet to ever do so). This of course also confirms my bias, held since I was first exposed to it, that VLC is bad---or specifically that VLC is fine software developed by fine folks if what you need is just an entire self-contained media playing app that can handle everything, but just crazy-making if you can notice the kinds of details I cannot help but notice.

That all being said, the practical suggestion in the sparse comments there are exactly what I was already thinking myself, that worst-case scenario I just have to make long long long loops as single files. Ideally it doesn't come to that though!

More substantial discussion of this might exist at https://forum.videolan.org/viewtopic.php?t=149226, but currently for me I'm getting an nginx gateway timeout instead of the forum thread. I'm gonna blame nginx being terrible software to double-down on the potentially unwarranted confirmation of my biases ;)

Another problem with VLC is that the application window is briefly visible, but I think I could get around that by having the orchestration script start up the new instance first and then kill the old instance, crude but effective.

Okay, actually I wayback machine'd it, which points in turn to https://code.videolan.org/videolan/vlc/-/issues/549 which in turn points to https://code.videolan.org/tguillem/vlc/-/tree/gapless-mr which was set to maybe be merged into VLC 4.0 . . . and maybe it still will be, but 4.0 isn't out yet anyways.

This may well end with me recompiling a version of VLC with that patched in. But there might also be an easier fix. The last comment in that forum thread reads as follows:

I managed to fix the micro-hang between playlist changes and looping all most entirely by reducing the value in File caching (ms)

• Preferences > All > Input / Codecs > Advanced > File caching (ms)
• The default value is 1000ms, I changed mine to 300ms.

Your mileage may vary, I found that the lower the number the less smooth the video would be, but the higher the number the longer the pause would be between loops. I also assume higher definition videos would need more caching.

Might not solve your issue, but hopefully this helps someone. :)

(VLC 3.0.14, Win10)

This further led me to https://wiki.videolan.org/Console/ which gives some ideas for remote control without having to kill an instance after starting another (though perhaps it could just be a playlist!), and also noticing

main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.

But back to the main thrust, the option in question these days lives in Tools → Preferences → change from Simple to All → Input / Codecs → the Advanced section (first item). Also, that option exists as file-caching= in ~.config/vlc/vlcrc. That's all cool but unfortunately even if I set the value to literally 0 it still stutters a liiiitle bit on my desktop, and even at 300 or so the performance is terrible on the Pi3, so that's not a viable solution.

I'm left with either:

1. Pre-render large videofiles that loop for a long time within the file itself
2. Recompile VLC from that unmerged branch
3. Something Else

Lets try something else for a bit!

Cribbing from a forum thread, I did find much more success with mpv run like so:

mpv --loop-file --vo=gpu --hwdec=v4l2m2m-copy --fullscreen "videos/pixabay_whitehexagons_21161-315224572.mp4"

which does get it to run without being super glitchy, but it's clearly not actually using hardware decoding or something else is going wrong because it's low-framerate and CPU usage is very high (though not even an entire core, which is somewhat promising), compared to VLC where CPU usage is negligible. (Funny enough, because it can't offload to hardware decoding, mpeg2 performance is notably way worse in VLC, using tons of CPU and visibly more jittery.)

--hwdec=v4l2m2m seems a tad better, but I go back to VLC and other than the goddamn pause on the loop it's way smoother, so alas. Hilariously, https://mpv.io/manual/stable/#options-hwdec doesn't even mention either option.

Maybe running in a session somehow even slimmer than openbox would help, but I kinda doubt, and of course VLC is proving that it's possible.

Okay, so, lets try to compile a fresh copy of VLC! Okay admittedly this is gonna be weird because the VLC version on Raspbian is patched for the Pi (available at https://github.com/RPi-Distro/vlc) and meanwhile that gapless fork is very outdated, so I'd need to merge the diffs in to a branch with the Pi changes too. Maybe this will all go super smoothly, I mean hey stranger things have happened ;)

Running in a terminal session unfortunately doesn't seem to really benefit either very much, but VLC's CPU usage is maaaaybe even lower, and it seems entirely viable and so could bypass the need for even something like openbox (which I'm mostly using to avoid polluting the shell init for testing, but this means it could easily be a systemd service for the production approach).

Also damn I really gotta use this 13" OLED monitor more at night, it's a beauty. Gotta resist the temptation to try to get a monitor . . .

Okay, back to compiling vlc.

# Install basic build dependencies as far as the package is ostensibly concerned
sudo apt build-dep vlc

# . . . and that was enough apparently to succeed at
./bootstrap
./configure
make

# and yup at that point it works to run
export LD_LIBRARY_PATH=$LD_LIBRARYPATH:/opt/git/vlc-rpi/lib
./bin/vlc-static

# So in that case,
git pull ../vlc-gapless
make

And that does create something that can be run, but annoyingly then it flickers while tossing a bunch of errors:

xcb vout display error: window not available
gl vout display error: parent window not available

And then trying it in Openbox it uhh crashes the entire user session. And running it on its own gives me a segfault when I try to mimic the options used in the cvlc shell script. Hrmmm.

Reckoning that maybe I was just running things wrong, I've decided to install the possible-abomination I've compiled.

checkinstall somehow only created a .deb full of the doc files rather than the binaries? Okay fine, oldskool, it's sudo make install time, that couldn't possibly go horribly wrong

Once installed, cvlc works for the self-compiled version, though also it just works fine with, say, vlc -I dummy --fullscreen --loop --no-mouse-events --no-keyboard-events --video-on-top --no-osd --mouse-hide-timeout=1 videos/some.mp4. But . . . it still visibly pauses. Arghh!

I've resorted to posting on a forum: https://forums.raspberrypi.com/viewtopic.php?t=386443