MS Stream ingest URLs (Usage and purpose)
What is the use and purpose of two ingest URL when it comes to encoder based events (MS Stream, Yammer or Teams encoder event) : We use AMS as a backend, here is what their documentation states on that (found here). Single encoder double-pushing to both primary and secondary URLs: The main purpose of this scenario is to provide more resiliency to network fluctuations and jitters. Some RTMP encoders don't handle network disconnects well. When a network disconnect happens, an encoder might stop encoding and then not send the buffered data when a reconnect happens. This causes discontinuities and data loss. Network disconnects can happen because of a bad network or maintenance on the Azure side. Primary/secondary URLs reduce the network problems and provide a controlled upgrade process. Each time a scheduled network disconnect happens, Media Services manages the primary and secondary disconnects and provides a delayed disconnect between the two. Encoders then have time to keep sending data and reconnect again. The order of the disconnects can be random, but there will always be a delay between primary/secondary or secondary/primary URLs. In this scenario, the encoder is still the single point of failure. The other redundancy scenarios listed there are not supported by stream. If the customer has sufficient bandwidth, a single encoder that can dual push (post encoding, not encoding twice), then dual pushing can provide help in some scenarios. However, when used incorrectly it can cause problems (e.g. two different encoded streams). In all cases we strongly encourage testing the setup being used including doing things like disconnecting, reconnecting as well as failing over to any backup encoder. It is also extra important that the encoders be configured for CBR (Constant bit rate) when dual pushing. Two different encoders must not be sending to primary and secondary at the same time. If a backup encoder is used, ideally it should be as close to the configuration of the primary as possible. But it should be tested thoroughly for fail over, and should take into account that updating one encoder or the other may cause failures in scenarios where previously it had succeeded. If the encoders are different, it may also be worth considering having a backup stream event that is separate. I hope this helps.. Cheers !!
