Video webserver

Question

Video webserver

Ameb opened this issue 4 years ago · comments

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 · Answer 1 · Sun Apr 19 2020 21:17:38 GMT+0800 (China Standard Time)

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?

Florian Magin · Answer 2 · Thu Apr 23 2020 15:38:55 GMT+0800 (China Standard Time)

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 · Answer 3 · Thu Apr 23 2020 16:53:54 GMT+0800 (China Standard Time)

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.

Florian Magin · Answer 4 · Thu Apr 23 2020 16:57:12 GMT+0800 (China Standard Time)

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 · Answer 5 · Thu Apr 23 2020 17:19:34 GMT+0800 (China Standard Time)

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.