A pure C Mjpeg-over-HTTP server
github.com
A pure C Mjpeg-over-HTTP server
1–10 of 19 posts
Re: A pure C Mjpeg-over-HTTP server
#2I'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.
Re: A pure C Mjpeg-over-HTTP server
#3Great 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!)
Re: A pure C Mjpeg-over-HTTP server
#4Projects 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 element I'm dying.
Re: A pure C Mjpeg-over-HTTP server
#5I 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.
Re: A pure C Mjpeg-over-HTTP server
#6Projects 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 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?
Re: A pure C Mjpeg-over-HTTP server
#7Projects 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 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 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.
Re: A pure C Mjpeg-over-HTTP server
#8Projects 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 element I'm dying.
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
Re: A pure C Mjpeg-over-HTTP server
#9Projects 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 element I'm dying.
You might like WebRTC Media, it's SRTP once all the session establishment stuff is done. (WebRTC Data is SCTP over DTLS)
Re: A pure C Mjpeg-over-HTTP server
#10Projects 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 element I'm dying.
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.