Question 103990 in Azure Question posted in
The official documentation to get you started can be found here.

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.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    After creating the api from scratch and breaking down a produced URL here is what I found.

    https://<stream-endpoint-url>/<stream-locator-id>/<manifestName>.ism/manifest(format=m3u8-cmaf)

    1. First creating a livestream you will by default have a Streaming endpoint from Azure Media Services. That or a streaming endpoint you create will be your `<-stream-endpoint-url>

    2. The streamLocatorId listed here unassumingly "properties.streamingLocatorId string The StreamingLocatorId of the Streaming Locator." is actually a 32 bit GUID. "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ***Note you can set this but in reality you should let this but probably should just let it randomly generate.

    3. The manifestName comes from creating the live output and is a property string you can set. "properties.manifestName string The manifest file name. If not provided, the service will generate one automatically."

    4. Lastly, /manifest(format for HLS or Dash) will complete the url.

    Unfortunately I couldn't find this in the documentation but hopefully this will help someone.

    Update:

    What I did find in the docs is this Stream Paths api.

    What's nice is about this is that it tells you what the paths are and you just need to concatenate the links together. However, this is a another call after the fact so interesting.


  2. 0

    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.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search