azurestreamingazure-media-services

How to construct a streaming URL for Azure Media Services live stream event? Where is the streaming locator path on the rest api call?


In either the rest api service or the sdk it is not very explanatory in the documentation on how to come up with a stream url.

In the Azure portal it will create one when you create a live streaming event, a live output and a stream locator.

Again, the documentation doesn't address this.

To make videos in the output Asset available to clients for playback, you have to create a Streaming Locator and then build streaming URLs. To build a URL, you need to concatenate the Streaming Endpoint host name and the Streaming Locator path.

Using the rest api where is the streaming locator path? It's not in the response as such.


Solution

  • A lot of the Samples show how to do this as well, the Node.js/Typescript ones are a good place to start, as all of the SDK's mirror each other and the REST API entities.

    One of the issues with the current Streaming locator API is that it does not give back the complete path... it's been a problem for a while for some customers and I would have preferred we built the whole path for folks. The reason we do not, is because we offer the flexibility of having multiple Streaming Endpoints (origin servers) in a single account. That allows some customers to build locators for live streams from one endpoint and VOD on-demand streams from a second endpoint that may have a different CDN configuration or caching setup, or CNAME, etc. Kind of our fault for providing too much flexibility - which leads to a complex API. I think we would not do that in a future simplified API.

    See this basic streaming example - https://github.com/Azure-Samples/media-services-v3-node-tutorials/blob/main/Streaming/StreamFilesSample/index.ts

       async function getStreamingUrls(locatorName: string) {
          // Make sure the streaming endpoint is in the "Running" state on your account
          let streamingEndpoint = await mediaServicesClient.streamingEndpoints.get(resourceGroup, accountName, "default");
        
          let paths = await mediaServicesClient.streamingLocators.listPaths(resourceGroup, accountName, locatorName);
          if (paths.streamingPaths) {
            paths.streamingPaths.forEach(path => {
              path.paths?.forEach(formatPath => {
                let manifestPath = "https://" + streamingEndpoint.hostName + formatPath
                console.log(manifestPath);
                console.log(`Click to playback in AMP player: http://ampdemo.azureedge.net/?url=${manifestPath}`)
              });
            });
          }
        }
    

    Note that you should try to avoid using the REST api directly and use the SDKs instead. Reason is that there is a lot of boilerplate retry logic that is required for Azure Resource Manager retries, etc. that is difficult to roll completely on your own unless you dig into that logic in the open source SDK of your choice and handle the Azure REST response objects and long running opertaion pattterns. I always encourage folks to avoid 'rolling their own language' SDK whenever possible. I've had big customer projects fail when they implemented it wrong or forgot to deal with certain retries.

    I had this added to the docs a while back to deal with that issue:

    Warning

    It is not advised to attempt to wrap the REST API for Media Services directly into your own library code, as doing so properly for production purposes would require you to implement the full Azure Resource Management retry logic and understand how to manage long running operations in Azure Resource Management APIs. This is handled by the client SDKs for various languages - .NET, Java, TypeScript, Python, etc. - automatically and reduces the chances of you having issues with retry logic or failed API calls. The client SDKs all handle this for you already.