What Protocol Is Right for Your Workflow: IngestApril 7, 2021
Live streaming workflows can vary immensely, but six key steps are often involved:
- Capturing the stream with a camera or smart device.
- Compressing the video and audio data using an encoder.
- Ingesting that content into a streaming platform like Wowza for processing.
- Processing and packaging the stream into its final format and protocol.
- Delivering the live stream across the internet (often using a content delivery network).
- Playing the content back on end-user devices.
This blog’s focus will be steps two and three, where content distributors must choose a protocol for first-mile contribution and ingest. Ingest describes the technology used to transport video files from the encoder to the streaming media server.
Unlike at the last-mile delivery portion of a streaming workflow, ingest protocols don’t need to be supported by end-user devices. Instead, broadcasters often select an ingest protocol based on speed and encoder support.
This is because the media server is often used to transcode and transmux the stream for adaptive bitrate delivery to a much wider range of devices. By letting the media server do the heavy lifting, broadcasters can keep things simple at the encoding step.
The most popular protocol for ingest is the Real-Time Messaging Protocol (RTMP). But that’s not necessarily because it’s the best. Much of its use has to do with the fact that the protocol is well supported on the ingest side and RTMP-based workflows are well defined. Specifically, many broadcasters choose to compress their stream using an RTMP encoder and then repackage it into an HTTP-based format.
In this blog, we’ll take a look at the most common protocols used for ingest and cover the recommended considerations when determining which protocol is best for your workflow.
RTMP ensures efficient video contribution but has disappeared from the publishing end of most streaming workflows due to the death of Flash. Many content producers encode their low-latency video streams using RTMP, and then repackage the stream into a more playback-friendly alternative once it reaches the media server. Using a combination of RTMP and HTTP technologies like HLS and DASH helps maximize compatibility without pushing latency too high.
- Low latency and well established.
- Supported by most encoders and media servers.
- Required by many social media platforms.
- RTMP has essentially died on the playback side and thus is no longer an end-to-end technology.
- As a legacy protocol, RTMP ingest will likely be replaced by more modern, open-source alternatives like SRT.
Another old-school technology for video contribution, RTSP facilitates low-latency streaming in many surveillance and closed-circuit television (CCTV) architectures. As with RTMP, most workflows using RTSP will leverage a media server to ingest the stream and repackage for delivery to viewing devices.
- Ubiquitous in IP cameras and thus is common in surveillance workflows.
- RTSP comes with many of the same limitations as RTMP, in that it’s a legacy protocol that’s slowly dying.
- Rarely used end to end since it’s not supported by Android or iOS devices.
- Not as well supported by encoders.
Secure Reliable Transport (SRT) is an open-source technology designed for reliable and low-latency streaming over unpredictable public networks. It competes directly with RTMP and RTSP as a first-mile solution but is still being adopted as encoders, decoders, and players add support. One interactive use case that SRT proved instrumental for in 2020 was the first virtual NFL draft — ensuring high-quality streaming and operational flexibility from anywhere with an internet connection.
- An open-source alternative to proprietary protocols.
- High-quality and low-latency.
- Designed for live video transmission across unpredictable public networks.
- Accounts for packet loss and jitter.
- Not natively supported by all encoders.
- Still being adopted as newer technology.
- Not widely supported for playback.
As the speediest technology available, Web Real-Time Communication (WebRTC) delivers near-instantaneous voice and video streaming to and from any major browser. The framework was designed for pure chat-based applications but is now finding its way into more diverse use cases. Scalability remains a challenge with WebRTC, though, so you’ll need to utilize a solution like Wowza Streaming Engine or Wowza Streaming Cloud to reach a larger audience.
- Easy, browser-based contribution.
- Low latency and supports interactivity at 500-millisecond delivery.
- Can be used end-to-end for some use cases.
- Not the best option for broadcast-quality streaming due to certain features to enable near real-time delivery.
HLS is an adaptive HTTP-based protocol most commonly used for transporting video and audio data from media servers to viewers’ screens. It isn’t ideal as an ingest format. That said, we occasionally see HLS used when someone needs to redistribute an existing feed. Using HLS end to end (for both ingest and delivery) might seem like a simple approach — but we’d recommend avoiding it for several reasons.
- Allows you to grab an existing feed and redistribute it.
- Higher latency.
- Not optimized for transporting video across an unpredictable network.
- HLS ingest could result in the packets getting out of order.
- There aren’t a ton of encoders that support HLS ingest streaming.
Considerations When Selecting a Protocol for Ingest
Wowza supports all of the ingest formats detailed above, meaning that it’s ultimately up to you. But we’d suggest asking the following questions to help narrow down your options.
Are you streaming directly to a social media platform?
Do you require simple, browser-based publishing?
When simplicity is the name of the game, and you’re hoping to skip using an encoder altogether, WebRTC is the way to go. The protocol allows you to start streaming in seconds with Wowza Streaming Cloud. Find out how in this video tutorial.
Do you need to transport broadcast-quality content across the public internet?
Only one of the protocols mentioned above was designed to address remote video contribution challenges: SRT. The cutting-edge technology also achieves that elusive combination of high quality and low latency that every live producer seems to be chasing.
Is real-time interactivity required for your use case?
If you need true interactivity — we’re talking sub-one-second video delivery for scenarios like emergency response and remote monitoring — then WebRTC fits the bill. It’s the fastest technology of the bunch and also can be used from end to end. SRT is also a good choice when you can handle a bit more of a delay, which is why the NFL used it to power the first entirely virtual draft.
Are you streaming from an IP camera?
RTSP remains standard in many surveillance and closed-circuit (CCTV) architectures for one reason: IP cameras commonly support it. But you’ll need a video repackaging solution to deliver the stream to end-user devices — and that’s where Wowza comes into play.
Start With Wowza
No matter what type of streaming architecture you’re trying to build, Wowza makes it happen. Our full-service platform can power any workflow with reliability to boot.