[geekmaster]

Woohoo! xz-compressed (level -4) is playing video on my K1. There is no problem using 900KB compression buffers if you use a version of busybox that is more than 1MB smaller than the version that fails. That huge full-featured busybox-v4l is fine and dandy, provided you only do stuff that needs very little RAM.

And now Big Buck Bunny is playing at about 2.5FPS (it will say how many measured FPS in the log file when in finishes), reading COMPRESSED data from SD card. I will try again with -9 compression instead of -4 compression, and that should increase the framerate (still limited by sequential waits for SD card reads AND framebuffer updates). Eventually, though it will make my code bigger, I will do double buffering, so I can do simultaneous waitings (as opposed to much less efficient simultaneous waits). Asynchronous I/O has its benefits when extra speed is essential, as is using multithreaded execution (the simplest way to go when we add sound playback into the mix).

So yeah, as mentioned in that 10-year-old "mmc" link I provided recently, reading from really slow SD card interfaces is much less of a problem if you are reading highly compressed data, and pre-dithered video compresses quite highly, which is a good thing when using eink displays.

I have chores to do now -- I will fix my "double-width pixel" problem by adding 2-bit pixels packing to gmplay, and then I will port my changes into my "video plus sound" version of gmplay.

EDIT: Big Buck Bunny finished played, and it reported on competion:
1163 frames in 621.7 secs = 1.9 FPS
I thought it was faster than that, but that means that my estimated speed was probably also slower for the uncompressed video playing from SD card. Now I am going to try -9 xz compressed playback. The videos are copying to my SD card (slowly via the kindle on USB) now.

EDIT2: Nope! With -9 compression it is reporting "xzcat: corrupted data" just like before. Perhaps the busybox xz function *is* double-buffering (which makes sense for a production program) and it needs almost 2MB to support a pair of 900KB compression buffers, and my smaller busybox only freed up about half that. That seems like an inappropriate error message though, in this case. I guess I could binary-search compression buffer sizes to see what works, but I may end up using something that will break on the next firmware update (if it leaves less free memory). I will just stick with -4 compression for now (diminishing returns, and other things to do with my limited time).

EDIT3: I suspect that at some point I *will* add a swapfile (or swap partition on my SD card), and then perhaps I will revisit using xz -9 compression on my kindle videos, to see it it *can* work on my K1. I do not see any other way to free up RAM, because I am already running in the "update install" environment (though I *could* free up some by having my install script "exec /mnt/us/RUNME.sh" instead of "sh /mnt/us/RUNME.sh", but then my install script would have no opportunity to clean up after itself -- but I can design for that).