Serve (or write to) an animated GIF or webp file using the emulator?

[jdesai61]

Is it possible to output to an animated GIF or webp file using the emulator? Idea is to then serve the output to tidbyt (or like device) over HTTP. Something like pixlet. The browser adapter does most of the work - except server just a raw image.

[ty-porter]

Sorry I didn't get to this sooner.

Just to clarify, you're saying streaming JPEG will not work for tidbyt compatibles?

I think this is a cool idea, maybe to port older custom matrix software to tidbyt. I don't own one though so I would be relying on community support for assistance there. Do they have docs on what formats they expect?

In terms of lift I think you're right, the browser adapter does the most work and would just need to be updated to the correct format.

[jdesai61]

The tidbyt hdk code simply pulls a webp image from a hard coded URL at regular interval. And it displays the animated frames in webp image in a loop. Besides the tidbyt device, the tidbyt HDK code runs on Ardunio Matrix Portal S4 as well. I have one working and can test. Tidbyt (or tidbyt HDK) doesn't support JPEG, mjpeg or animated gif.

[ty-porter]

I see the HDK is just polling whatever endpoint is configured
https://github.com/tidbyt/hdk/blob/2486250b6f22b753d8b61283c95423db1e0054a8/src/main.c#L47-L59

The current browser adapter serves images over a websocket so don't think that will work, but shouldn't be too hard to expose an HTTP endpoint that serves a configurable format.

[jdesai61]

I didn't realize that support has already been added. Will try it out in a couple of days.

[jdesai61]

I just verified that the emulator works with tidbyt HDK ported to Adafruit Matrix Portal S3 (https://github.com/mrjefftang/hdk), albeit with right half side display being blank - issue reported here #62 (comment)
I don't have actual tidbyt device, so unable to test with it.
I had to change pixel_width to 1 and display size is to 64 columns and 32 rows.

[jdesai61]

Adding this support allows one to separate physical display location from application logic. I can run my apps on my NAS/PC/Cloud and have multiple tidbyt or other similar Matrix Displays served by it.

[riffnshred]

Yes this is a game changer !

[riffnshred]

Something written in Javascript (or something else), rendering images the conventional way would be even better. The RGB matrix python binding is slow to generate images. I did extensive testing at a certain point and could do fast enough animation (23-25 fps if I remember correctly) with it, but my Raspberry Pi was sweating bullets and was not running anything else.

[ty-porter]

If you're referring to the FPS display on the browser adapter it's decoupled from RGBME actually rendering the frame. For the default browser adapter the emulator targets 24 FPS as a baseline but that's how fast the browser is requesting a frame from the emulator-- there's used to be a memory leak using browser blob storage like that.

I don't have instrumentation regarding how fast each frame is drawn by the emulator, everything I've tested has been "fast enough"

[ty-porter]

Also note there is a PR in the pipeline to speed up that adapter

#61

[jdesai61]

Now that I am testing this some more, the current implementation meets certain application requirements - where the image is being periodically updated by tidbyt and doesn't change between pulls.

However, what I am realizing is that typical tidbyt apps (running on server or community apps here: https://github.com/tidbyt/community) don't just create a static webp image. They actually create an animated webp image with multiple frames. So for example a digital clock may generate a single webp image with animated frames for a full minute. Then tidbyt may pull image over HTTP every minute (or some other interval). A scrolling text for example is sent in one webp image with animated frames.

The animation interval and # of frame in each webp image is decided by the application, so not sure how to achieve similar results in the emulator context.

[ty-porter]

Yes in that scenario the tidbyt architecture is fundamentally at odds with this library then (RGBM / RGBME requires you to drive LEDs in real-time).

A solution would be to place middleware between RGBME -> tidbyt that "records" images and compiles them to the appropriate format and serves with the appropriate cache TTL. Even then there would be a processing delay and you would see a "jerk" when the cache misses

[jdesai61]

Placing something between RGBME and tidbyt doesn't may help - but ultimately, app that produces the content knows how many frames need to be in an image and how they need to transition. As you said, the two architectures are different and an application aware solution might be needed. For now this works well enough - I was able to follow MLB exhibition game on my display - with slight scrolling inconsistencies. Thanks for your help

[samueljrodriguez]

Wanted to follow up on this. Did anyone get this working? I also wanted to emulate this on my NAS and push it to http.