Maybe SRT, but it doesn't have much platform support itself, and its spec is pretty strange. I get weird Adobe flashbacks about it, since it seems so heavily pushed by Haivision, and it's really made for a different use case - it's made for big broadcasters like ESPN and TV networks, not for web startups.
The current motion seems to be towards hacking WebRTC to accommodate broadcast ingest. But WebRTC is really huge and complicated and you only want a tiny sliver of it for this use case. Pretty much all implementations are buggy because its such a gigantic kitchen-sink design.
There's also RIST (for those who love working groups) and Zixi (for those who love closed source protocols?).
I honestly think that something like HLS could do pretty well (broadcaster slices video into 1-second TS segments and just ships em with HTTP POST), but it's not something I ever saw anyone do. Definitely doesn't meet the TV networks' needs, but its really easy to scale and straightforward to secure, which is maybe more important.
WebRTC really isn't that big. Google's implementation just is targeted at their needs. If you are doing it for ingest you just need
* Basic SDP library, ICE-Lite, DTLS, SRTP
If you ship RIST you pretty much end up with the same thing!
If you go with WebRTC you have implementations in lots of languages as well (not just bindings)
* Go, Python, Pure C/Embedded, Java, Rust, C++
Also WebRTC could let you do SVC or Simulcast. It would be a lot better for scaling if the uploader sent all the different quality feeds (and let congestion control ensure they don't oversend).
I really feel that there has been a concentrated marketing effort that has hurt WebRTC on multiple fronts.
* Google oversells what they have done. They bundled up a bunch of existing protocols. That doesn't get as my promotions/awards though. It also helps them control the standard. If they paint 'Google WebRTC === WebRTC' then they make a change and everyone else has to play ball.
* WebRTC competitors want to paint it in a bad light so they can sell $x
I dunno, https://www.w3.org/TR/webrtc/ seems pretty huge to me. And then there are all the RFCs and notes you need to also read and understand, and then you realize that the real spec seems to be Google’s implementation... that at least was how things felt in 2018. They totally might have progressed since then.
Yes, you can pick from the WebRTC buffet and build a good ingest protocol, but you need a lot of knowledge to do that - I would guess a tiny tiny number of people who read your comment know what DTLS or even STUN are.
I also agree that there is a branding problem, but I think part of it is that we don’t have a good name for this WebRTC ingest pattern. It deserves a name and some attempt at standardization so tools and software can start building towards it without supporting everything in WebRTC.
Because yeah, I think its the least-bad thing we have right now.
I think you must be the same Sean-Der who works on the Go WebRTC library? Thanks a ton - that’s serious open source work.
I have been working on https://webrtcforthecurious.com/ to solve that. It approaches WebRTC from the protocol. I also try to give credit/real history at the end!
I played around with https://github.com/Sean-Der/webrtc-uri but I don't have any experience/friends in the IETF/W3C so it is never going to happen. I agree it would be really amazing. It would be great if a company that had influence picked it up!
Yea I work on Pion! Thanks for using it :) I get a real sense of purpose trying to make WebRTC more accessible/easier to use. I love seeing what people build. Also really feel in love with teaching because of it. It sure has taken up a lot of my time, but 100% worth it.
(SRT itself is a defunct file transfer protocol that's had some life brought back into it by Haivision)
Big broadcasters tend to go for "open standards" from groups like SMPTE and DPP. The "DPP001 - Live IP Profile" recommendation has a variety of different profiles depending on the importance of the media and the network that's involved, but it generally revolves around MPEGTS over RTP, with either dual streaming (sending the same packets down two different networks), or RIST (so a NACK based error correction), or perhaps both. Certainly when I broadcasted major international TV events recently, I've gone for both RIST and two networks.
The last thing you want is your signal to drop out for 10 seconds due to a power failure while your network reroutes just as the final touchdown at the superbowl happens - or worse in the the commercials.
I work at Mux, though I don't have any special sauce on this. Instead, as a small broadcaster (Twitch and the occasional event--I ran Demuxed this year from my home office!), SRT is a godsend. I throw video around my studio all the time, because NDI has weird frame timing issues and sucks up a lot of bandwidth, and I don't always need real-time video. I would absolutely love it as a predictable, latency-configurable (within some parameters, of course) ingest method for streaming.
(disclaimer: I'm participating in the libRIST development)
RIST! It's a well thought out protocol without technical debt (which SRT has), supports multicast (if you need it), null packet deletion, encryption via PSK or DTLS and multiplexing (multiplexing support in libRIST is not fully there yet, it's on the roadmap together with DTLS).
Next iteration of the RIST protocol will support "backpressure" on your encoder, so if you have too much packet loss your encoding can scale it's video bitrate down, while together with null packet deletion you'll be able to keep your bitrate perfectly CBR.
This sounds interesting but until it's in ffmpeg and/or obs (being in ffmpeg would put it in obs more or less by default eventually now I think) that'll limit its practical usefulness for a lot of people. Is that planned/being pushed for?
RTMP is very old as a protocol and pretty rubbish.
But not because it's old. IP is old. UDP is old. RTP is old.
Using TCP for live streaming isn't a good thing, same as using TCP for a VPN isn't good.
SRT isn't great, it grew from a file transfer program (UDT). UDP file transfers like UDP and Signiant were popular 15 years ago when TCP window scaling and buffers were more miss than hit. Companies like signiant and filecatalyst were very big on them, and UDT was an attempt to standardise it.
RIST is technically a far nicer protocol than SRT, but suffered massively from the talking-shop development. It came out two years late, and even then didn't have the proper libraries to just drop into your prosumer camera like SRT did.
N.B. It's a shame as their file transfer management systems were good (control, monitoring, security, scheduling etc), but they were going full pelt on the "TCP is slow, UDP is fast" line - to the point that they deliberatly took standard linux distributions like ubuntu and redhat, and changed the default settings to disable tcp window scaling, so show a "side by side" comparison on their sales booths at events.
What would you recommend as an alternative modern protocol to RTMP for shipping video between a broadcast endpoint and transcoding/distribution infra?