A pure C Mjpeg-over-HTTP server (opens in new tab)

(github.com)

39 pointsnola-a4y ago18 comments

18 comments

I 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.

stackedinserter4y ago

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.

cardiffspaceman4y ago

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?

nola-aOP4y ago

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.

1 more reply

stackedinserter4y ago

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.

theamk4y ago

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

rurban4y ago

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.

stackedinserter4y ago

Send RTP via TCP then, it will fix all problems you mentioned.

BTW what is so complex in RTP?

1 more reply

ranger_danger4y ago

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.

stackedinserter4y ago

Latency.

andrewf4y ago

You might like WebRTC Media, it's SRTP once all the session establishment stuff is done. (WebRTC Data is SCTP over DTLS)

stackedinserter4y ago

Are there production-ready solutions for WebRTC streaming to multiple people (not p2p)?

1 more reply

nevets9634y ago

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.

rasengan4y ago

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!)

[1] https://www.stunnel.org

j / k navigate · click thread line to collapse

18 comments

addaon4y ago

stackedinserter4y ago

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.

cardiffspaceman4y ago

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?

nola-aOP4y ago

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.

1 more reply

stackedinserter4y ago

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.

theamk4y ago

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

rurban4y ago

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.

stackedinserter4y ago

Send RTP via TCP then, it will fix all problems you mentioned.

BTW what is so complex in RTP?

1 more reply

ranger_danger4y ago

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.

stackedinserter4y ago

Latency.

andrewf4y ago

You might like WebRTC Media, it's SRTP once all the session establishment stuff is done. (WebRTC Data is SCTP over DTLS)

stackedinserter4y ago

Are there production-ready solutions for WebRTC streaming to multiple people (not p2p)?

1 more reply

nevets9634y ago

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.

rasengan4y ago

[1] https://www.stunnel.org

j / k navigate · click thread line to collapse