Hacker News new | ask | show | jobs
by theamk 1613 days 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

2 comments

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.