The authorization backend can now update the stream configuration for each session. We have implemented 2 new mechanisms in the authorization context. On_publish is a mechanism for authorizing publishing sessions and on_play is for playback sessions. Both options are useful to use with templates. On_publish. When interacting with a UGC platform, streamers (publishers) use different cameras and different equipment for publishing. Also, UGC platforms can monetize the service by offering streamers various tariff plans and features: DVR, restreaming to YouTube, etc. If the streamer, for example, switches to a different tariff plan or simply changes his device for publication, the authorization backend will transmit this information. It will return the updated configuration before the stream starts (before the video publication begins). At the same time, the config file of the Flussonic ingest servers remains static and it will not change with the change in the number of users. This will make it possible to quickly, without additional settings add resources when the load on the service increases (for example, during the weekends). In addition, on_publish allows for an accurate and quickly balancing of the transcoder pool behind the ingest servers. On_play. In one of our previous releases, the rewrite mechanism was implemented to create playback streams with a dynamic (previously unknown) name. However, rewrite was a separate option inside the Flussonic config – it was necessary to explicitly specify "rewrites” for each stream/publishing location, etc. Using on_play, unlike rewrite, will allow having a static configuration on all restreamer servers. Configuration parameters are changed only 1 time at the authorization backend layer. The authorization backend will quickly provide relevant information like where is the transcoder with the required stream for a specific playback session. This is especially important in the context of large streaming platforms with tens of thousands of open sessions. In this case, using peer and source mechanisms would translate into a long search for the right stream through the list of servers. Find outhow to use the options. A new mechanism for embedding ads by replacing stream segments within the play session has been introduced The stream segment changes in real-time to a segment from the commercial in each playback session. The URL of the segment with the ad remains the same for all viewers of the stream. At the same time, different ads can be shown to different viewers from the same URL. It is impossible to distinguish the URL of the main stream segment from the URL of the advertising segment. This additionally protects the ad from being cut out. Available for HLS and DASH (both for multi-period and mono period manifests). Allows you to make unique ads targeted for each user or session without transcoding. The equal duration of the original stream segments and the commercial ensures smooth switching between segments (the stream will not crash during commercial breaks). Please note that it is necessary to preprocess the ad clips before using them in ad insertion. This new way of embedding ads is the first step towards improving the entire monetization module through advertising. In the near future, we are going to implement the SCTE ad insertion markers, as well as to build a convenient system for preparing commercials for the insertion. The new mechanism for embedding ads by replacing stream segments is enabled by the v2 option in the authorization backend settings. Find out how to do it. A new API design with OpenAPI 3.0 specification has been implemented There are some principles that we have followed: Ensure standardized access methods to different systems Formalizing a list of service methods and the input and output data formats. Rejection of super-complex query string parsing rules in favour of the JSON query language. Providing dynamically changing data at any time (e.x., stream bitrate). Learn more about Flussonic HTTP API.