Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A pure C Mjpeg-over-HTTP server

github.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: A pure C Mjpeg-over-HTTP server

#11

Post by rurban »

theamk wrote: post #8
stackedinserter wrote: post #4

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

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.

Re: A pure C Mjpeg-over-HTTP server

#12

Post by nola-a »

cardiffspaceman wrote: post #6
stackedinserter wrote: post #4

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

Re: A pure C Mjpeg-over-HTTP server

#13

Post by stackedinserter »

theamk wrote: post #8
stackedinserter wrote: post #4

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

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

BTW what is so complex in RTP?

Re: A pure C Mjpeg-over-HTTP server

#14

Post by stackedinserter »

ranger_danger wrote: post #10
stackedinserter wrote: post #4

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

Latency.

Re: A pure C Mjpeg-over-HTTP server

#15

Post by stackedinserter »

andrewf wrote: post #9
stackedinserter wrote: post #4

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

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

Re: A pure C Mjpeg-over-HTTP server

#16

Post by nousermane »

stackedinserter wrote: post #13
theamk wrote: post #8

Earlier quoted context omitted.

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

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.

Re: A pure C Mjpeg-over-HTTP server

#17

Post by stackedinserter »

nousermane wrote: post #16
stackedinserter wrote: post #13

Earlier quoted context omitted.

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.

Re: A pure C Mjpeg-over-HTTP server

#18

Post by stemcc »

stackedinserter wrote: post #15
andrewf wrote: post #9

Earlier quoted context omitted.

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.

Re: A pure C Mjpeg-over-HTTP server

#19

Post by cardiffspaceman »

nola-a wrote: post #12
cardiffspaceman wrote: post #6

Earlier quoted context omitted.

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

Post reply on HN