search

rien / reStream

Stream your reMarkable screen over SSH.
MIT License
775 stars 58 forks source link

Video webserver #23

Open Ameb opened 4 years ago

Ameb commented 4 years ago

It would be cool to optionally run a webserver on the host machine, similar to srvfb. This will allow to use reStream on Windows, or share the video on LAN (or even over the internet).

rien commented 4 years ago

Good idea! You're always welcome to look for a way to implement this and create a PR. I think ffmpeg will probably be able to create a video stream. So maybe this just needs the right ffmpeg paramters?

fmagin commented 4 years ago

I think a webserver like srvfb would be fairly overkill, but ffmpeg can just output a video stream in typical formats. The main issue will be getting an ffmpeg binary that is optimized to work on the reMarkable by using NEON instructions (the one in entware doesn't).

This would be cool for Linux too, because it would allow a .socket service like srvfb, so you can just point whatever videoplayer to your reMarkable IP, and it will start the stream and should stop it when the videoplayer disconnects

rien commented 4 years ago

I'm not so sure that running ffmpeg, even with NEON instructions, on the reMarkable will be doable. I think the CPU is just not powerful enough to run xochitl, encode a live video stream, and run a webserver at the same time.

It seems more feasible to me to use the same compression stream we have now, but do the decompression and displaying in the browser trough JavaScript.

fmagin commented 4 years ago

I would expect ffmpeg to allow configuring the encoding of the live video stream, and just allow "raw" at worst. My intuition is that surely there is some encoding that works as at least as well as the lz4 scheme and implementation that is used currently.

The fact that ffmpeg is probably optimized for reading out the frame buffer efficiently should also be taken into account.

rien commented 4 years ago

I would love to be proven wrong here, but that was my experience when experimenting with different transportation methods. The main reason why I chose lz4 is because it is especially finetuned for embedded devices, requiring as few CPU cycles as possible to achieve an agreeable compression ratio.

You might have a point on optimized reading of the framebuffer though.