Can we create same streaming url instead of multiple streaming urls when we stop and create the same live streaming event multiple times.

Question

Hi @Xavier Pouyat
I wanted know is there any setting or steps that we can follow to create same streaming url instead of multiple streaming urls when we stop and create the same live streaming event multiple times.

Whenever a live video streaming event is stopped and started again a new output asset is created and a new output streaming url is created. Can we create same streaming url for the same event even if the event is started and stopped multiple times? Also can we only keep one output asset for single event when we start and stop the same event multiple times?

Answer 1

Hello,
No, you cannot easily use the same streaming URL if you stop and start a live event. Each time you create and publish a new live output (and asset), a new streaming URL (GUID) will be used for the new locator. That way, you are sure there won't be any cache conflict in the Streaming Endpoint and the CDN. You can prepare (and know) the streaming URLs in advance because you can force a specific GUID for the streaming locator, and decide the manifest name to use for the live output.

So let's say, you decide to use GUID 1a7ed69e-a361-433d-8a56-29c61872744f for the live output that you will create tomorrow. When this day comes, you start the live event and create a live output. You can decide to use "conference1" for the manifest and force the GUID for the locator.

The Streaming URL is predictable and is :

http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest

To your second question : no, you cannot reuse the same live output / asset multiple times. {Live output + asset} is like a recording. Once the live has been recorded to the asset, you cannot reuse it for another recording. There will be blobs conflicts. If you purge the blobs, potentially you can reuse it but please don't go this route. There will be issues because the fragments have been cached in the streaming endpoint, CDN or customer device.