A pure C Mjpeg-over-HTTP server

A pure C Mjpeg-over-HTTP server(github.com)

39 points by nola-a 4 years ago | 18 comments

addaon 4 years ago |

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.

stackedinserter 4 years 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.

cardiffspaceman 4 years 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-a 4 years 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.

stackedinserter 4 years 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.

theamk 4 years 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

rurban 4 years 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.

stackedinserter 4 years ago | | |

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

BTW what is so complex in RTP?

ranger_danger 4 years 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.

stackedinserter 4 years ago | | |

Latency.

andrewf 4 years ago | |

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

stackedinserter 4 years ago | | |

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

nevets963 4 years 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.

rasengan 4 years 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