Ok Monitor

[bmsleight]

OkMonitor

Making an OK Monitor from one or many e-readers.

• VGA or HDMI connection
• Resolution 1024x768 or lower
• 5 fps - 6 inch screen or
• 6 fps - 12 inch screens
• Wireless, around 2 hours+
• lag of around 1.2 seconds.

Big thanks to:-

• NiLuJe
• GeekMaster - their code lives on.
• OpenWRT
• Raspberry PI
• JoppyFurr
• This forum (mobileread.com - Kindle Developer's Corner)

Hardware needed, PI4, microSD card, USB HDMI Capture, (optional VGA in to HDMI out), Kindle Paperwhite V1 (one or four)

Software; MIT License.

Warning: Please do not skip installing Coward's Rescue Pack.
Warning: Grants SSH access to kindle via known key
Warning: Connects via a local wifi network, with known password

Overview and more details: https://barwap.com/projects/okmonitor/

Finished it before the end of the year.

[bmsleight]

*reserved*

[NiLuJe]

You *might* be able to achieve better performance if the ordered dither and rotate is moved to the transcoder, and then simply throw the frames at FBInk's print_raw_data.

As long as the input is actually 8bpp (which ffmpeg can do just fine, IIRC), that boils down to a memcpy, so, very fast.

Alternatively, FBInk can do the dithering for you (and it's relatively cheap). It could technically do the rotation, but not in a cheap way, and not on a Kindle.

EDIT: Well, it can do 16c dithering for you. Which is aimed at quality, not speed. For videos, if you really want speed, you'd possibly want a bitonal dithering and switch to A2 waveform modes.
On some devices, the *kernel* can do that for you, though: c.f., https://github.com/NiLuJe/FBInk/blob...nk.h#L237-L240 & https://github.com/NiLuJe/FBInk/blob....c#L1813-L1820

As for the rotation, an easier solution would be to cheat and rotate the framebuffer to Landscape first w/ fbdepth, that does work on a Kindle.

(c.f., FBInk's doom PoC).

[bmsleight]

Originally Posted by NiLuJe

You *might* be able to achieve better performance if the ordered dither and rotate is moved to the transcoder, and then simply throw the frames at FBInk's print_raw_data.

Just when you think a project is finished!

God, my C skills need improving. I like the idea - ffmpeg could transcode this easier and maybe I could use a "lessor" PI. Might even reduce lag down as well.

The rabbit hole of toolchain set-up awaits.

Any hints how to stream to fbink ?

[NiLuJe]

Well, it's C, so, sky's the limit . There's networking involved, so, probably sockets though. Either in a way that keeps boundaries so you read frame-by-frame, or a stream that you chunk yourself into frame-size bytes before pushing that to FBInk.

Or keep going through an extra shell layer that uses nc to dump that in a local FIFO, but that seems like a waste when you can just do nc's job in C directly ;p.

[NiLuJe]

As far as toolchains go, https://github.com/koreader/koxtoolchain (or KOReader's docker images).

[bmsleight]

Thank - useful.

The limitation is CPU speed at the moment. From the limited tests I have run. ffmpeg & raw2gmv is limited by CPU speed.

Or keep going through an extra shell layer that uses nc to dump that in a local FIFO, but that seems like a waste when you can just do nc's job in C directly ;p.

When I only have a hammer in your toolkit, everything looks like a nail. I need to improve on my c & sockets skills. I have not done socket in c for 20 years.... even then not well.... Bare metal is fun. Might investigate https://github.com/NiLuJe/py-fbink/blob/master/hello.py

However, as per you first reply - a better way could be - transcoder then simply throw the frames at FBInk's print_raw_data. I expect ffmpeg is do that quickly, even if I need to split the screen in to quarters again.

As far as toolchains go, https://github.com/koreader/koxtoolchain (or KOReader's docker images).

Firing up a debian vm....

I pretty sure - based upon loopback test that the USB HDMI capture is never going to be better than 800ms https://barwap.com/projects/okmonito...ation/#/laglag But shaving off the other 400ms would be good. Also fbink is on more than just PW1.

Any thoughts on max fps for fbink ?

[NiLuJe]

Will depend on screen resolution, and ultimately the bottleneck will be the EPDC, not FBInk (as I said, for 8bpp data, that's a memcpy, so, barely a few ms).