A pure C Mjpeg-over-HTTP server
github.comI implemented something like this in a previous life. One thing I did was to insert JPEG comments into each frame containing an encoding marker (speex, etc) and audio data. This allowed a standard consumer to see the MJPEG image as normal; but a modified client (including within a browser, using javascript) could decode the audio and video in sync and play back with sound.
Projects like this is a clear indication of industry's failure to provide a decent protocol for low latency streaming to browsers. Just give me MPEGTS/RTP in <video> element I'm dying.
But isn't MJPEG a decent protocol for streaming to browsers? The browser handles MJPEG streams as the URL. It also handles the URL for a stream from Motion as the SRC element of an IMG element.
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?
Mjpeg over Http is not a live streaming format, it takes a lot of bandwidth, it has high latency, it run on TCP which it is not a protocol for streaming, the only advantage is that all browsers support it.
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.
My use case at the moment is to get the video my STB at the office is showing to show in real time in a window on my laptop at home. Currently I use a webcam pointed at a monitor connected to the STB, and I use motion to make the MJPG available. The laptop has a VPN connection to the office and can connect to the HTTP server in motion. I need to be able to resolve text when it is a fairly light color on a supposedly contrasting fairly light background. In practice with the webcam and Motion I'm close. Frequently the text part doesn't quite work.
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.
MJPEG is just a stream of JPEG pictures, delimited by some boundary.
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.
I'd say no, RTP has incredible complexity and does not play well with proxy, NAT, connection forwarding, and many things.
We do need a video transport better than MJPEG, but please don't make it RTP-based
Because RTP is pure UDP and UDP is complex?? The complex parts are the service protocol RTSP and the TCP variants over HTTP, like this, which need an ack packet for every packet sent.
Just use VLC, as everybody else.
Send RTP via TCP then, it will fix all problems you mentioned.
BTW what is so complex in RTP?
> Send RTP via TCP
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.
Just a friendly reminder that the alternative is sending MP4 or MPEGTS chunks via HTTPS with terrible overhead and latency. Also, we're discussing it in a thread about something that converts camera stream into MJPEG.
> 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.
You can already do HLS live streaming in a browser with MPEGTS and a simple .m3u8 playlist file that auto-refreshes to get the new segments.
Latency.
You might like WebRTC Media, it's SRTP once all the session establishment stuff is done. (WebRTC Data is SCTP over DTLS)
Are there production-ready solutions for WebRTC streaming to multiple people (not p2p)?
Sure, there are multiple production-grade SFUs. Janus, Mediasoup, etc.
I've done work before where we stream USB cameras via mjpg using https://github.com/pikvm/ustreamer
Granted this project looks like a lot more streamlined.
Great job on this project - really cool and useful. I put a tiny-PR on the README with a note about gaining TLS functionality through stunnel [1] (all good if it isn't merged, but figured it might be helpful to those who wish to use with TLS!)