Teams Live-Event with RTMP ingest
Dear all, I have a couple of questions regarding the new Teams Live-Events with RTMP ingest (using an external encoder). So far I´ve been using MS Stream live-events for professional livestreams with an external encoder and it worked great. But since the Stream live-events will be shut down at some point this year, I have to make the switch to the Teams live-events (with RTMP ingest). Is there an option to disable all automatic audio enhancement functions (like noise reduction, etc.)? If I stream music/spoken language to the live-event it doesn´t sound as good as with the Microsoft Stream live-events. Do teams live-events with RTMP ingest offer a buffer in case one of the viewers has an internet problems? Because to me it seems like the RTMP In live-events work rather like a general Teams Video-Call, so that in case of internet problems the audio will still be audible and the image will freeze. Usually streaming platforms have a buffer that will be filled to prevent audio-video dropouts. How do live-events in MS Teams in general differ from the live-events in MS Stream? Thanks in advance for your help! Best regards.
Audio quality when using Teams Townhall with rtmp-in.
Hi everyone I have broadcast a live music (orchestra) concert using Teams Townhall with rtmp-in (using Blackmagic Design web presenter). When I checked the archive recorded on Teams, I realized that the volume of the music is being ducked automatically. All my audio sources are mixed down with a professional digital mixer before streaming to Teams so basically they have a good balanced. I have another back-up recorded data and it does not have the same problem, so i think it is caused by the algorithm of Teams, and even if I am using an external encoder?? Is there a method to fix this problem? I have compared the data recorded by the external device and teams. The ducking is quite obvious. Lower: Recorded on Teams Townhall Thank you Cheers CarsonMS 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 !!
