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.