-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Video webserver #23
Comments
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? |
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 |
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.
|
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. |
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.
|
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).
The text was updated successfully, but these errors were encountered: