A pure C Mjpeg-over-HTTP server(github.com) |
A pure C Mjpeg-over-HTTP server(github.com) |
MPEGTS would be great for things I have wanted to do in the past, and all you probably have to do is hack the video element so it can handle that.
I think the thing about MJPEG and webcams is that it's relatively easy to make MJPEG from a webcam. MPEGTS would require more code I think?
So (i) if you want a solution that works out of box on any device, (ii) if you have enough bandwidth and (iii) if you are not interested in video quality, Mjpeg over Http is a good trade-off.
Therefore no audio and compression/quality is shit. Also, MJPEG stream doesn't have timestamps, so it's impossible to provide smooth playback of MJPEG stream, or synchronize it with other streams.
We do need a video transport better than MJPEG, but please don't make it RTP-based
Just use VLC, as everybody else.
BTW what is so complex in RTP?
Granted this project looks like a lot more streamlined.
I was using ffserver also.
I don't particularly need the HTTP layer nor the browser itself. But I can tell a colleague on the office network: Look at my $WEBCAM_URL to show them something on my STB so that's nice. If I could say "ffplay $WEBCAM_PARAMS_AND_IP_ADDRESS" and it was available within the office, that would be the same.
Please don't. TCP is entirely inadequate for streaming because of head-of-line blocking behavior. Nobody use RFC4571 for that very reason.
You can make TCP/HTTP work for streaming, but that usually involves developing some fragile system that does chunking, buffering, and retries. Probably implemented as a sizeable pile of custom idiosyncratic Ajax.
> You can make TCP/HTTP work for streaming, but
RTMP works via TCP just fine, although it's not the best protocol either (but better than HLS)
> sizeable pile of custom idiosyncratic Ajax
I don't want it to be handled in JS. Let's just add RTP/RTMP/SRT/whatever support to browsers. They already include full ffmpeg libraries anyways.