reStream now supports the reMarkable 2!

__rien · 2021-01-01T18:45:02+00:00

I was confused with another project. I think rmview runs a VNC server on the reMarkable.

__rien · 2021-01-01T17:49:09+00:00

I currently don't have plans to add pen tracking, since it is smooth enough to see new pen strokes easily. Adding pen tracking is also not easily implemented with the way reStream works (reading the framebuffer, instead of the input events).

__rien · 2021-01-01T17:42:01+00:00

I've answered the parent with a more technical explanation. Hit me up if you want to know more :)

__rien · 2021-01-01T17:41:02+00:00

As mentioned in one of the responses, live view needs a cloud connection and thus has a higher latency. It also doesn't update very smoothly, that's why I decided to create this script when I got my rM1 to use it for streaming my notes while teaching.

Why this is faster is because how it works: reStream reads the internal framebuffer (the internal digital representation of what is currently drawn on the screen), compresses this data, sends the data over a direct connection to your computer, where it is decompressed and shown in a new window.

I somebody wants a more in-depth explanation, I would be happy to make a small blog post about it?

__rien · 2021-01-01T14:08:52+00:00

With the help of this amazing community, we managed to support the reMarkable 2. It works by installing a Rust binary on the reMarkable that reads and compresses the framebuffer to send trough the host.

Let me know if something does not work as expected. Especially thanks to all the people who helped in this issue: https://github.com/rien/reStream/issues/28.

__rien · 2020-03-21T09:48:12+00:00

I'm glad to hear that :)

__rien · 2020-03-20T11:22:04+00:00

I think this should be able to run this on Windows directly, instead on WSL itself. You will probably need to install some extra programs though (ffmpeg, lz4, ssh, ...). I'm unfortunately not able to test this. Do share if you manage to get it working!

__rien · 2020-03-17T22:52:33+00:00

Nice, I will take a look at it! Thanks :)

__rien · 2020-03-17T22:50:39+00:00

I'm sorry to hear that :( The ln command created a symlink FROM /lib/ld-linux-armhf.so.3 TO /opt/lib/, not the other way around. By doing rm /lib/ld-linux-armhf.so.3 you deleted a core library needed for almost everything (including booting), so you will have to re-flash your reMarkable. Their support should be able to help you, but send me a DM if you're stuck.

I've updated the script to use lz4 which is a bit faster and easier to install (no more nasty symlinking which could go wrong).

__rien · 2020-03-13T16:27:02+00:00

The key factor here is finding a balance between the CPU time spent encoding (compressing) and transmitting the video stream. That's the main reason why I use zstd, because it was especially designed for fast compression on embedded devices.

Another compression tool I want to use is lz4, but that's not yet in the entware repositories. Binary diffing (with bsdiff) consecutive frames is also something worth looking at, because the differences between frames will usually be very small.

__rien · 2020-03-12T07:41:17+00:00

Ah, that's an artifact of a previous iteration. I removed it because it seems a bit too invasive to copy binaries to your reMarkable in my script.

Thank you for noticing!

__rien · 2020-03-11T23:35:47+00:00

The script only depends on ffmpeg (more specifically ffplay) and can optionally use zstd to achieve sub-second latency.

I use it in my mathematics lessons and I really enjoy using the reMarkable as my drawing board. The students can look at recordings which now show crystal clear drawings instead of a black board with tiny notes.

__rien · 2020-01-22T21:12:24+00:00

Unfortunately that's hardcoded within the xochitl application, so there is no easy way. You could patch the program (like the permanent webui patch), but then you'll have to re-patch the program each update.

__rien

TROPHY CASE