What Protocol Is Right for Your Workflow: Ingest (Update)
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.
- Transcoding 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 or 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. Rather, RTMP is well supported on the ingest side by encoders and media servers. For that reason, many broadcasters choose to compress their stream using an RTMP encoder and then repackage it into an HTTP-based format.
In our 2021 Video Streaming Latency Report, 76.6% of broadcasters indicated that they use RTMP for video contribution, followed by 24.74% leveraging WebRTC, and 21.13% streaming with SRT.
Which streaming formats are you currently using for ingest?
In this blog, we’ll take a look at the most common protocols used for ingest and considerations when determining which protocol is best for your workflow. Whether you’re reevaluating your current workflow or looking to narrow down your options, the information below is sure to help.
RTMP
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.
Benefits:
- Low latency and well established.
- Supported by most encoders and media servers.
- Required by many social media platforms.
Limitations:
- 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 and WebRTC.
RTSP
Another old-school technology for video contribution, the Real-Time Streaming Protocol (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.
Benefits:
- Ubiquitous in IP cameras and thus is common in surveillance workflows.
Limitations:
- 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 widely supported by encoders as RTMP.
SRT
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.
Benefits:
- 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.
Limitations:
- Not natively supported by all encoders.
- Still being adopted by encoders and servers
- Not widely supported for playback.
WebRTC
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.
In the past, WebRTC was restricted to browser-based publishing, but streaming vendors are working to eliminate this obstacle. One technology called the WebRTC HTTP Ingest Protocol (WHIP) provides encoding software and hardware with a standard signaling protocol when talking to media servers, thus removing WebRTC connectivity barriers between encoders and media servers. At Wowza, WebRTC is the underlying technology powering our Real-Time Streaming at Scale feature for Wowza Video, and we’re building WHIP support into our future OBS implementation for the feature.
Workflow: Real-Time Streaming at Scale
Benefits:
- Easy, browser-based contribution.
- Low latency and supports interactivity at 500-millisecond delivery.
- Can be used end-to-end for some use cases.
Limitations:
- For broadcast workflows that require fine-tune control over encoding settings (including bitrate, codecs, and codec parameters), WebRTC encoding and ingest is not yet widely supported across vendors.
HLS
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.
Benefits:
- Allows you to grab an existing feed and redistribute it.
Limitations:
- 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 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?
If so, RTMP is your best bet. Most encoders can transmit RTMP, and most social media players (Facebook, YouTube, and Twitch) accept it.
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 Video. 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. Our Real-Time Streaming at Scale feature combines the hyper speed of WebRTC with distribution to large audiences, making it a great option for any interactive video environment
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. We offer protocol flexibility on the ingest side as well as on the delivery side — meaning you’re able to design the best streaming solution for your use case rather than sticking with one prescriptive workflow.