The TelVue HyperCaster supports ingest of RTMP (Real Time Messaging Protocol) streams. What follows is a primer on the RTMP protocol and how you might use it.
What is RTMP?
RTMP is a protocol developed by Adobe designed for real-time (live) video streaming across the internet. While Flash streaming has declined over the years, the RTMP protocol remains the primary method for streaming encoders to deliver to CDNs (Content Distribution Networks). Given it is 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 Push vs. RTMP Pull
RTMP has two primary methods of transport- Push, where a streaming encoder delivers the RTMP to a RTMP Server or CDN, 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 a TeleCast 2 streaming encoder, 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. The HyperCaster can also pull using other more modern protocols include HTTP Live Streaming (HLS).
Firewall Considerations
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.
To add the RTMP feed to the HyperCaster:
- Click on Config. Under Feeds click on Live Streams.
- Click on the small icon in the bottom-left of the table to add a new stream source
- Change the type to RTMP. Enter a name and description of your choosing.
- Enter the address address of the RTMP stream.
- Optionally enable Stop on Loss of Signal. By selecting this checkbox, any stream/record event created using this feed will automatically end when the source signal is lost. You can set a tolerance, for example to deal with noisy networks or the Internet, to allow some number of seconds of signal loss without considering a loss and time to stop via the Schedule Configuration settings.
- Optionally enable Start on Trigger. By selecting this checkbox and Manual Trigger Type from the pulldown, any stream/record event created using this feed will only start after it is manually triggered from the dashboard by clicking the Trigger action button
from the Now Playing / Now Recording sections. For live stream events, the channel will display Continuity while waiting for the trigger. - Click Save.
- You can preview the stream within the HyperCaster web interface, if the stream is running, by clicking on the blue link under URI.
- The RTMP stream can now be scheduled as you would schedule any other stream in the Programming tab, either Calendar or Classic view. RTMP streams can also be used as sources in Series Scheduling for automatically scheduling reoccurring and episodic events.
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 “stopped.” 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
The HyperCaster will transmux incoming RTMP feeds to a Transpport Stream with an efficient, variable mux rate. Customers using the RTMP feature in an IPTV plant need to be especially careful of mux rate as the downstream gear in your facility may not handle variable mux rate. 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, or models such as the HyperCaster AIO on the channel that’s outputting the RTMP feed do not need to take this into consideration as the decoder will be able to handle in-stream changes to the bitrate, muxrate, and resolution without issue.
Latency
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 a few and 15 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: https://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.
