What is RTMP?
RTMP is a protocol developed and maintained by Adobe designed for real-time (live) video streaming across the internet. Most of us know it as “Adobe Flash,” although that’s not wholly correct as it’s only one part of the Flash suite. Lots of devices in the marketplace rely on RTMP to reliably deliver live audio and video to CDN’s (Content Distribution Networks) and Edge devices such as desktop computers. In recent years RTMP has been adapted for video backhaul across the open internet. Given its TCP based, and thus stateful, it has built-in resiliency when used as a transport across networks that might have some packet loss, such as the public internet. RTMP is also very ubiquitous. For example, any customer who streams using the TelVue CloudCast platform, Youtube, or UStream, is using the RTMP Protocol, and anybody at home viewing that stream on their computer is watching an RTMP feed.
RTMP Push vs. RTMP Pull
RTMP has two primary methods of transport- Push, where a streaming encoder delivers the RTMP to a RTMP Server, and Pull where the client retrieves the stream and plays it back. The TelVue HyperCaster can take RTMP inbound connections both ways, though the “push” process would probably be the more common use case. An RTMP Push process means that if you have a device or application that can output RTMP like Flash Media Live Encoder (FMLE), a Teradek Cube, Telestream Wirecast, a NewTek TriCaster, the LiveU Solo, or multiple other hardware or software solutions you can deliver that feed directly to the HyperCaster via LAN, WAN, or Internet. Once the device is setup and the HyperCaster configured this method will allow you to go live from virtually anywhere that you have a reliable internet connection. This is likely the most common use case for stations using the feature whereby you will be pushing a stream directly to the HyperCaster for ingest and processing.
RTMP Pull, while it’s still the same protocol, uses a slightly different process. In this model the HyperCaster would be reaching out to a RTMP server or CDN on the internet and retrieve a stream to playback. Take, for example, you may need to share a live stream with multiple HyperCasters at once, possibly in geographically different areas. You could configure your RTMP encoder to stream to a CDN such as the TelVue CloudCast player, and then have multiple HyperCasters “tune in” and retrieve that stream. This may be useful if you’ve got a football game that two stations need to simulcast, or perhaps a large community event that needs to be distributed to dozens of places at once.
In the RTMP Pull method, firewalls tend to not be an issue. This is because the HyperCaster is requesting a stream from the internet, and thus a stateful firewall would permit that request since it originated from behind the firewall. Think of this like inviting someone into your home. You open the door, invite them in, and they walk through. However, RTMP Push methods are a completely different story. Borrowing our example from above, this method has no invitation; you have to leave the door open for the guest to walk through on their own, otherwise they can’t get in. RTMP operates on TCP port 1935 meaning with a RTMP Push you would have to configure your firewall to permit that traffic into the HyperCaster. Most routers make it fairly easy to add such a rule and many stations have an IT staff (either contracted or full time) that can help you set this up. The majority of modern routers/firewalls call this “Port Forwarding” or “Destination NAT.” Some routers refer to it as “Applications.” Firewall configuration will only be an issue if you’re trying to send the HyperCaster a stream from outside your LAN. IE: if you’re streaming from one side of the station to the other, you likely don’t have to traverse the firewall (since both devices are already behind it.)
RTMP URL’s and Server Configuration
RTMP URL’s have a standard structure and vary based on several different things, not the least of which is Push vs Pull methods.
RTMP Push: You have to configure both the encoder and the HyperCaster with the proper RTMP URLs to work correctly. Starting with the HyperCaster receive side:
In this instance the HyperCaster is actually acting as it’s own RTMP server, hence we’ve put in 127.0.0.1 (“localhost” would also work here since it’s the same thing.) “telvue-rtmp” is the application name that we’ve applied to any feeds that the HyperCaster is being pushed. This is a static name and cannot be changed. Finally you’ve got the “Stream Name” which is a dynamic setting that you, the user, can choose. In this example the stream name is “fmle” but this designator could be “studio-a” or “town-hall-feed.” Pick something descriptive, but know that all stream names MUST be unique. This is especially important if you’ve got multiple RTMP streaming encoders pushing simultaneous feeds to the HyperCaster as this is how the server will distinguish which stream is which. Make sure to write it down for when you go to configure the encoder. One note here, you can’t use any special characters, with the exception of the “@.” or spaces in the stream names. Letters, numbers, dashes, and underscore are all permissible. The stream and application names are case sensitive.
Once you’ve configured the HyperCaster you now must configure your RTMP Encoder. Since every encoder is slightly different you may have to refer to the specific manual. Below are two examples from Wirecast and Flash Media Live Encoder (FMLE). Note the URL structure here mirrors the above URL but has two key differences:
1- The Address of the RTMP Source is the address of the HyperCaster
2- The stream name is a separate text entry block. Not all RTMP Encoders do this.
Wirecast here also shows you the fully concatenated URL which mirrors the structure below.
Once the streamer is fired up and running, you’ll see a bitrate appear in the HyperCaster feed configuration page.
RTMP Pull: Since the stream is “ready to pull” all you have to do is configure the HyperCaster to go retrieve that stream and pull it into the system. The example below would mirror the format for how the CloudCast system works using an Akamai style URL.
Once the stream has been added to the HyperCaster it will begin pulling it in, if it’s available. You will see a bitrate listed if the stream is present. Note: the stream is ALWAYS pulling regardless of it’s status on a channel unless it’s “disabled.” This means if you have limited download bandwidth at the station you need to be aware of how many active streams, both push and pull (but especially pull) are active at any given time.
Mux Rate and Streaming in IPTV Plants
When creating an RTMP feed entry in the HyperCaster, you must enter a Mux Bitrate. It’s important that this bit rate be higher than the bitrate of the incoming video stream. Most streaming bitrates are going to be between 1 and 5 Mbps, but if you are unsure of what the bitrate of the stream is we suggest setting the mux rate significantly higher than would otherwise be reasonable. For example you could set the stream to a 20 Mbps mux which would cover nearly every situation. This also means the resulting captured file will be larger; so while this method ensures that the stream will work properly, setting the mux rate appropriately based off the actual video bit rate is preferable. A rough calculation of how to get mux rate: (video bitrate + audio bitrate) * 1.1. This would give you a 10% overhead. Example: (2.25 Mbps + 0.192 Mbps) * 1.10 = 2.7 Mbps Mux Rate (rounded up.) If you’re using an RTMP encoder that is manually configured, you’ll be able to find the audio and video bitrates for the purposes of this equation.
Customers using the RTMP feature in an IPTV plant need to be especially careful of mux rate settings as the downstream gear in your facility may require a specific muxrate. Additionally, you need to take extra consideration regarding the matching of elementary stream codecs and resolution. Most RTMP encoders are going to output H.264 and AAC audio at a resolution of your choosing. If this matches the channel you intend to push the stream out on, then you’re in good shape, if not, there could be issues with downstream splicers, groomers, transcoders, stat muxes, and STB’s receiving and transitioning between regular programming and a feed coming from the RTMP encoder as streamed by the HyperCaster. Customers using a TelVue ProVue decoder on the channel that’s outputting the RTMP feed do not need to take this into consideration as the ProVue decoder will be able to handle in-stream changes to the bitrate, muxrate, and resolution without issue.
As is true with any encoded video, there is latency involved with the RTMP receive feature of the HyperCaster. In our testing we’ve found there is between 4 and 17 seconds of latency, depending on the encoder and network conditions, between “real time” and “channel delivery.” Latency should be expected and accommodated when scheduling and going live while using the RTMP ingest feature of the Hypercaster. This may mean you schedule the event to start later than it actually does, or you start your live shoot earlier than the actual start time. If you’re not using a direct connection to the Hypercaster (push process), and are instead pulling a stream from a CDN or OPV (Online Video Platform), latency could be considerably greater.
A Bit About the Internet and Video Transport
We’ve talked a bit about video transport across the public internet in the past. Here’s a blog post discussing it a bit more in depth: http://www.telvue.com/2013/10/28/video_backhaul/.
For the purposes of this document we do however need to discuss a few very important things about live streaming across the internet:
The internet was not really designed for low latency video transport: it’s architecture is extremely complicated and inherently latent. We take a lot of things for granted, as in recent years it has become significantly more viable to move live video across the web, but there are still quality issues that can be encountered. Know that as you’re using this feature, while we’ve done everything we can to ensure the server performs well, there are many, many things outside the control of the HyperCaster that can cause the stream to fail, drop, pixelate, or respond erratically.
If you’re experiencing issues with a link that has worked in the past, and none of the settings in either the HyperCaster or the streaming encoder have been modified from their “known working” configurations, the the problem is very likely the link and NOT the streaming encoder or the HyperCaster. Never forget there are NO guarantees that a stream will be able to transmit across the internet cleanly or with 100% reliability.
As such, we’ve included the ability to restart an individual RTMP stream on the HyperCaster side. We’ve guarded against every error we can, but invariably, when dealing with the complexity of the internet, something’s going to go wrong. As the end user, if a stream is in peril, you can login to the HyperCaster interface, go to the Config → Feeds page and click the “power button” and restart the RTMP stream process. In some cases this may fix the issue you were having, in others it may not have any effect on the RTMP stream. See image below highlighting the “restart” process button.
Tips for “Best Results”
Always test the RTMP streams in advance of use, especially RTMP Push streams. Regardless of “It’s always worked here before” mentality.
Do some comprehensive testing of the encoder before going live for the first time. This will ensure you’ve got the settings tuned for optimal transmission.
Run some speed tests on your local internet connection to verify how much download bandwidth you’ve got available.
Run speed tests on the remote internet connection to ensure the remote location has enough upload bandwidth.