I am thinking of trying to write an alternative to the content-streamer which allows dynamic brightness (Allow brightness to be changed while an animation is playing).
Not the led-image-viewer command-line utility - via an API (like the content-streamer API)
AFAIK @marcmerlin has done this - would appreciate your input, along with anybody else’s.
I would want to keep CPU usage as low as possible (ie it’s not a whole lot of use to me if it consumes twice the battery that the current content-streamer does), and also keep the startup time as low as possible - ie when one animation finishes, I do not want a perceivable gap before the next animation plays. I do not want to have to specify multiple animations in one API call to achieve this - I want one API call for an animation, animation finishes, then the next one is triggered with another API call.
AFAIK, when you create a stream file currently, it packs the file exactly as it needs to be sent “over the wire” (So basically most of the matrix options are baked into the stream file). I do not wish to change this, all I want to be able to control on the fly is brightness. IDK how brightness actually works under the hood (Does it change RGB? On time of pixels?) - I am wondering if some half way house unpacking could be done whereby 99% of the work is done, and it just needs to do some basic post-processing to adjust the brightness. I would also be happy with a system that only let you turn brightness down, never above that which it was set at when the animation was converted.
Finally, what are people’s thoughts about rolling this into the library? Should it be a separate API, or an alternate mode of the existing content-streamer?
Brightness is an option you can control at runtime on the matrix object when it is created.
From what I think I understand, you need to add a hook in the content streamer to control the brightness variable of the matrix object it creates.
And otherwise yes, you indeed could reprocess your streams to be less bright
Sorry, I should maybe have been clearer. I think we had this discussion before…
I am talking about streams. AFAIK brightness is baked in to the stream file as it literally has everything in exactly the state it needs to be ready to be sent “over the wire”
In the normal content-streamer mode, there is a delay before starting while it unpacks the file and converts it - I am trying to find a half-way house whereby it does a bunch of the work up front, enough to make it so that it can start playback ASAP.
Gotcha, in the case I don’t know, I’ve never used that code. I use animated gifs and push them frame by frame to my own 2D library where I also control brightness real time (which I can change on the fly while the gif is being animated)
Sorry for double-posting Clive, I know I covered this elsewhere but wanted to just chime in on the brightness thing as this was a critical success factor for me. Recreating led-image-viewer, forking or just building your own with AI is really easy, while I never took a base GIF and run with that I did have it pre-render a new RGB format which loads instantly, allows dynamic brightness control among other things, and the Pi4 has cycles to spare, no jitter, flicker, and in my implementation used a shm in linux for the dynamic brightness changes so it adjusts on command while running.
It may even work from a base GIF with no performance loss but I was already doing pre-rendering of equirectanglar cube mapping which resulted in a new RGB format stream. However you do it you’ll end up with a single RGB stream file rather than one per brightness which was what I was doing beforehand.
I had very explicit requirements which might be a square peg in a round hole as far as suggesting this be included in the core library, but if you build something from scratch that works and is clean, I’m sure it would be a welcome addition.
Good luck, and really looking forward to seeing what you come up with!
I got it to output to a new file format (.fseq for “Frame Sequence”) that’s pretty much just unpacked data.
Seems to not be a huge amount more energy drain. Playing a legacy .stream consumes 8W according to my bench PSU, and the new .fseq method consumes about 8.22W
When showing at a different brightness from what I wrote the fseq file as, there seems to be no noticeable difference in power consumption
So that seems good. According to our calculations, that should drop the typical runtime on my battery from ~10h to ~9h50m. Seeing as I have never run the battery down anything like too low in the past, that sounds totally acceptable.
Startup time for a .fseq seems basically instant, just like a .stream
This is all with basic matrix options though, I have not pushed the refresh rate yet. I will need to do some tests to see if I can still get refresh rate up to 400hz, and whether the power consumption is acceptable when I do so.