I just made a PR to the docs with some notes about streams, but there is some other stuff that maybe needs addressing.
-l<loop-count> : For animations: number of loops through a full cycle.
This is inaccurate. It affects images too.
If only one image is specified on the command-line, -f is effectively inforced, and you need to use -l1 if you only want to show the image once. This is true for a normal image, or a stream of an image.
In order to only show the image once, you must specify -l1(And probably a -w5 too to specify how long to show it). -w5 on it’s own does nothing.
The same is not true for animations - only supplying one file which is an animation on the command-line only shows it once.
So, for consistency, I suggest that if the command-line only specifies a single image, -f is not enforced.
Also, I have just noticed - if you convert an image to a stream, it is impossible to play that stream for a fixed amount of time if it’s the only thing on the command-line:
-l1 -t4 Plays for ~1sec
-l1 -w4 Plays for ~1sec
-t4 Plays forever
Is there any difference between playing an image as a stream or as the raw file (jpg, png etc)? I would have thought so - surely when you convert an image to a stream, it pre-decompresses it, so it can show faster, with less CPU usage? @marcmerlin - if that is the case, then this should be raised as a bug surely?
My honest answer is that example code probably has lots of issues and corner cases. I’ve personally never really used it.
You can file a bug if you wish, but realistically unless someone cares about that code and sends patches, it’s not super likely to get fixed.
The core library, there is more of an incentive to fix real problems, but example code is indeed just example code and not guaranteed to be complete or perfect