For those hosting larger events, you can utilise our redundant path when streaming to the platform. This is to ensure that if one of your streaming connections somehow fails another will pick it up.
If you would like to stream to your Hopin Stage using RTMP, you will need to head to your Event Dashboard > Venue > Stages to get started. Here, click on the RTMP Stream tab and you will be presented with both Preferred and Fallback destinations.
The reason behind having two different endpoints is to give you more redundancy when streaming to the Stage.
Do I need to stream to both destinations?
At Hopin we recommend you stream to both destinations where possible, if your configuration allows for this (see notes below). This is because by streaming to both endpoints you minimize the impact of failures in your customer’s viewing experience.
To highlight this further, say for any reason your connection to the preferred endpoint gets disconnected. Having a fallback endpoint set up means that your stream won’t end and instead the customer will notice a short delay or black screen when the stream switch happens.
How do I set this up?
A recommended scenario is given below, at a minimum we recommend you separate the encoders and network path:
- Separated feeds coming from your source
- Separate hardware encoders, one for each endpoint
- Separate networks, one for each encoder with enough bandwidth to support the livestream bitrate
- A UPS or some form of redundant power supply to ensure if one power source fails another will pick up
- A wired network connection
You simply configure each of your encoders to stream to a different endpoint, the rest we take care of! In the event of failure the switch happens automatically as explained in the previous section.
What if I can't stream to both endpoints?
If you are unable to adhere to the recommendations outlined above, even at the minimum level then it’s not recommended to set up a redundancy path.
The reason behind this is that you might do more harm than good, for instance streaming to the preferred and fallback on one network with limited bandwidth will not give you the expected results. Again, a wireless network is not recommended here due to stability issues.
Similarly, you might think it could be practical to stream on one computer with different types of streaming software, however it is important to note that CPU usage could spike and cause a degraded experience on both the preferred and fallback endpoints.
Finally, a few notes:
To get the best results, here a few final tips:
- Only attempt to stream to both endpoints if you have hardware encoders that support streaming to preferred and fallback destinations
- Have a wired connection with enough bandwidth to support both streams
- Best practice is to isolate your infrastructure when streaming to both endpoints. Think of using a different encoder, power source, network path etc. to reach the endpoint.
- Do NOT use a Wireless connection to stream to Hopin - video traffic does not behave well on such a network and this can cause quality issues in the stream.
- Please follow the recommended encoder settings guide to ensure a smooth streaming experience.
- The preferred endpoint logic is something to bear in mind when you have intermittent connectivity issues. The last thing you want is for your customers to receive a degraded viewing experience. For instance, if you know that your stream to the preferred endpoint is prone to continuous outages it might be best to stop streaming to this endpoint altogether and to fix the issue before starting it up again as it will cause continuous switches from a player perspective.
- If you do lose connectivity to a particular endpoint your recording will essentially stop and when the switch happens a new recording will start. What this means is that on the recordings tab in the dashboard you will see multiple recordings for your event which will correspond with the times when a switch occurred.
Feel free to reach out to us at email@example.com in case you have questions or need assistance.