jpschroeder
Crazy idea: stream video in real-time (say up to 5 seconds delay)
I wonder whether pipe-to-me could be (mis)used to stream video in real-time to multiple web clients. One way (i.e. only curl->pipe-to-me->web_browser) would be fine, no need for bidirectional piping.
Thoughts?
The idea is to have absolutely minimal clients using "plain old web technologies" while leveraging as much of web browser built-in functionality as possible (in this case especially the ability to play videos without any JS and hopefully without full prefetch as I would like to stream "indefinite" things like a conference).
Latency should be say up to ~5 seconds to make it usable I think :wink:.
This is a very interesting idea. I was able to get a proof of concept running locally by changing the response type to webm using:
w.Header().Set("Content-Type", "video/webm")
I opened firefox to a random key.
I then piped my local webcam to the key using some like this:
ffmpeg -f v4l2 -i /dev/video0 -c:v libvpx -f webm - \
| curl -T- http://localhost:8080/somekey
It did actually work, but has a number of downsides at the moment.
- The browser had to be opened first and wasn't able to pick up in the middle of a stream.
- It worked in Firefox and not in Chrome.
- It had a 5-10 second delay.
For the POC to work, I would need to allow the client some control over the content type that they are expecting.
It's not exactly viable at the moment, but definitely worth exploring further.
Awesome!
From my experience ffmpeg adds some delay (up to few seconds), the video encoding to webm takes non-negligible time (seconds) and the default optimization of the webm content is not meant for low-latency so I would not focus on that for now.
But as you write the "show stopper" for now is the fact the browser has to be opened first. Do you think this could be completely lifted by employing some JS, chunking or whatever... or rather not?
But as you write the "show stopper" for now is the fact the browser has to be opened first. Do you think this could be completely lifted by employing some JS, chunking or whatever... or rather not?
Any preliminary ideas?
I do not know whether I will find some time for this around Christmas but I am eager to learn some details which could push me to take a look at this earlier :wink:.
@ViBiOh I noticed you have plenty of experience with streaming. If you had a few minutes and could chime in here and share your knowledge, I would be very grateful. Thanks a lot!
Hi, thanks for thinking of me. My use case is a bit different when I used ffmpeg.
I need to convert the video into a more easily streamable version, its HLS version. In short, it splits the video into smaller chunks that are easier to proceed. But I do this locally and then expose them. It's not converted in live (as it consumes a lot of resources depending if the video codec is done on hardware or software).
Overall, on my personnel test cases, I had a lot of issues when piping content from/to ffmpeg. I had cleaner output when storing file locally, generating output locally, and then uploading them at their final storage place.
@ViBiOh I also thought of your experience with the server<->browser video "streaming" :wink:.
I don't do particular things also, I rely on the browser implement. When it's HLS, you send the .m3u8 file and the built-in player knows how to handle it (it's encoded in h264 why is broadly supported).
If it's not re-encoded, you rely on the browser support and most of the browsers will ask content with the Range HTTP Header to buffer input properly.