WebRTC-HTTP ingestion protocol (WHIP)
1–10 of 12 posts
Re: WebRTC-HTTP ingestion protocol (WHIP)
#2The current state of media ingest protocols is actually getting interesting. For quite some time its been a situation of 'everyone supports RTMP so you support RTMP' plus 'vendor X does not support $FANCY_NEW_PROTOCOL but they do support RTMP'.
Now we've got this fun competition between various protocols at different stages of their lifecycle. Some are SRT where one vendor is pushing them quite hard and support is flakily available but not everywhere. Others, like WHIP, are much earlier in their lifecycle.
Most new protocols support carrying more codecs without gross hacks and generally are much nicer than an early 2000s protocol which hasn't really ever had a canonical specification; beating RTMP is a somewhat low bar. Each one also has their own shiny ribbons like using QUIC/webtransport or very-low latency.
The next few years will be interesting to see which gets adoption and which get dropped at the wayside. Could be any of the current contenders; I'm just hoping I can stop maintaining an RTMP stack sometime before 2040 without suffering from extreme fragmentation.
Re: WebRTC-HTTP ingestion protocol (WHIP)
#3i hope this gets through.itd currently a pain to rewrite the signalling logic everytime I change provider
Re: WebRTC-HTTP ingestion protocol (WHIP)
#4Very interested to see if there is development in the WebRTC streaming ingest world. As far as I remember, the last major implementation was Mixer’s FTL (which has an open-source SDK implemented in OBS, but the server side was proprietary - though it has been reverse-engineered).
Also interested in comparisons between WebRTC and SRT, in particular for low-latency high-quality streaming (the niche between traditional streaming like RTMP and more conventional WebRTC apps where latency trumps quality).
Re: WebRTC-HTTP ingestion protocol (WHIP)
#5Question, Why encryption after quic. Well I know that quic 8s not adopted yet. But let's say if it does do we need the encryption provided inside webrtc. And whouldn't that be redundant. Spatially considering the whole point of RTC is to get a stream of data from one point to other as fast as possible.
Re: WebRTC-HTTP ingestion protocol (WHIP)
#6Very interested to see if there is development in the WebRTC streaming ingest world. As far as I remember, the last major implementation was Mixer’s FTL (which has an open-source SDK implemented in OBS, but the server side was proprietary - though it has been reverse-engineered). Also interested in comparisons between WebRTC and SRT, in particular for low-latency high-quality streaming (the niche between traditional…
There is a simple WHIP server and client here:
https://github.com/meetecho/simple-whip-server https://github.com/meetecho/simple-whip-client
Re: WebRTC-HTTP ingestion protocol (WHIP)
#7The current state of media ingest protocols is actually getting interesting. For quite some time its been a situation of 'everyone supports RTMP so you support RTMP' plus 'vendor X does not support $FANCY_NEW_PROTOCOL but they do support RTMP'. Now we've got this fun competition between various protocols at different stages of their lifecycle. Some are SRT where one vendor is pushing them quite hard and support is fl…
Sorry for going off topic a bit, but what is wrong/not ideal with RTMP? I've been using RTMP with Nginx for a couple projects and didn't notice anything inherently wrong. However, I was working with streaming for the first time so whatever problems I ran into were probably overlooked as a part of learning the tech.
What problems do you have with "maintaining an RTMP stack" does any of these newer protocols alleviate? What do you mean exactly by RTMP stack so I can be sure I understand you correctly? Thanks.
Re: WebRTC-HTTP ingestion protocol (WHIP)
#8The current state of media ingest protocols is actually getting interesting. For quite some time its been a situation of 'everyone supports RTMP so you support RTMP' plus 'vendor X does not support $FANCY_NEW_PROTOCOL but they do support RTMP'. Now we've got this fun competition between various protocols at different stages of their lifecycle. Some are SRT where one vendor is pushing them quite hard and support is fl…
Sorry for going off topic a bit, but what is wrong/not ideal with RTMP? I've been using RTMP with Nginx for a couple projects and didn't notice anything inherently wrong. However, I was working with streaming for the first time so whatever problems I ran into were probably overlooked as a part of learning the tech. What problems do you have with "maintaining an RTMP stack" does any of these newer protocols alleviate?…
Honestly, RTMP is a workhorse that powers most live video ingest today; its not bad, its just mostly frozen in time. Some issues that came immediately to mind are:
- It was developed to support flash; if anyone is sending metadata about the data streams are probably serializing flash objects, which is truly an experience when writing go.
- The supported codecs are limited and the spec provides no generic way to extend it. If you want h264 and aac, RTMP is great. If you want any codec developed after that, you need to either reach for another protocol or use a non-standard extension to RTMP whose support across different providers is flaky.
- Its TCP under the hood and that locks you to a fixed reliability/performance tradeoff.
- The 'spec' is a document released by Adobe which is not particularly great, falling pretty far short of what we'd expect out of the IETF or similar. Its overly detailed in some areas and woefully under detailed in others.
- RTMP isn't particularly tune-able; if you want to tradeoff latency for quality or similar, you're exploring the dark depths of the protocol.
None of these are damning but, as an aggregate, they go a long way to encouraging new protocols to be developed which avoid these issues.
> What problems do you have with "maintaining an RTMP stack" does any of these newer protocols alleviate? What do you mean exactly by RTMP stack so I can be sure I understand you correctly?
Re: WebRTC-HTTP ingestion protocol (WHIP)
#9All this talk of RTMP without a mention of RTSP feels a little strange.
I have seen RTSP scale quite well, is widely supported and in the form of an open and clear standard.
Re: WebRTC-HTTP ingestion protocol (WHIP)
#10Earlier quoted context omitted.
Sorry for going off topic a bit, but what is wrong/not ideal with RTMP? I've been using RTMP with Nginx for a couple projects and didn't notice anything inherently wrong. However, I was working with streaming for the first time so whatever problems I ran into were probably overlooked as a part of learning the tech. What problems do you have with "maintaining an RTMP stack" does any of these newer protocols alleviate?…
Honestly, RTMP is a workhorse that powers most live video ingest today; its not bad, its just mostly frozen in time. Some issues that came immediately to mind are: - It was developed to support flash; if anyone is sending metadata about the data streams are probably serializing flash objects, which is truly an experience when writing go. - The supported codecs are limited and the spec provides no generic way to exten…
Thanks for the answer. I was not aware of all those details and sounds like I had a relatively easy time with RTMP since both projects I built, coincidentally, used either ffmpeg or OBS.