Live streaming with Azure Media Services v3
Looking for Media Services v2 documentation?
Azure Media Services enables you to deliver live events to your customers on the Azure cloud. To stream your live events with Media Services, you need the following:
A camera that is used to capture the live event.
For setup ideas, check out Simple and portable event video gear setup.
If you do not have access to a camera, tools such as Telestream Wirecast can be used to generate a live feed from a video file.
A live video encoder that converts signals from a camera (or another device, like a laptop) into a contribution feed that is sent to Media Services. The contribution feed can include signals related to advertising, such as SCTE-35 markers.
For a list of recommended live streaming encoders, see live streaming encoders. Also, check out this blog: Live streaming production with OBS.
Components in Media Services, which enable you to ingest, preview, package, record, encrypt, and broadcast the live event to your customers, or to a CDN for further distribution.
For customers looking to deliver content to large internet audiences, we recommend that you enable CDN on the streaming endpoint.
This article gives an overview and guidance of live streaming with Media Services and links to other relevant articles.
You can use the Azure portal to manage v3 Live Events, view v3 assets, get info about accessing APIs. For all other management tasks (for example, Transforms and Jobs), use the REST API, CLI, or one of the supported SDKs.
Dynamic packaging and delivery
With Media Services, you can take advantage of dynamic packaging, which allows you to preview and broadcast your live streams in MPEG DASH, HLS, and Smooth Streaming formats from the contribution feed that is being sent to the service. Your viewers can play back the live stream with any HLS, DASH, or Smooth Streaming compatible players. You can use Azure Media Player in your web or mobile applications to deliver your stream in any of these protocols.
Dynamic encryption enables you to dynamically encrypt your live or on-demand content with AES-128 or any of the three major digital rights management (DRM) systems: Microsoft PlayReady, Google Widevine, and Apple FairPlay. Media Services also provides a service for delivering AES keys and DRM (PlayReady, Widevine, and FairPlay) licenses to authorized clients. For more information, see dynamic encryption.
Dynamic filtering is used to control the number of tracks, formats, bitrates, and presentation time windows that are sent out to the players. For more information, see filters and dynamic manifests.
Live event types
Live events are responsible for ingesting and processing the live video feeds. A live event can be set to either a pass-through (an on-premises live encoder sends a multiple bitrate stream) or live encoding (an on-premises live encoder sends a single bitrate stream). For details about live streaming in Media Services v3, see Live events and live outputs.
When using the pass-through Live Event (basic or standard), you rely on your on-premises live encoder to generate a multiple bitrate video stream and send that as the contribution feed to the Live Event (using RTMP or fragmented-MP4 input protocol). The Live Event then carries through the incoming video streams to the dynamic packager (Streaming Endpoint) without any further transcoding. Such a pass-through Live Event is optimized for long-running live events or 24x365 linear live streaming.
When using cloud encoding with Media Services, you would configure your on-premises live encoder to send a single bitrate video as the contribution feed (up to 32Mbps aggregate) to the Live Event (using RTMP or fragmented-MP4 input protocol). The Live Event transcodes the incoming single bitrate stream into multiple bitrate video streams at varying resolutions to improve delivery and makes it available for delivery to playback devices via industry standard protocols like MPEG-DASH, Apple HTTP Live Streaming (HLS), and Microsoft Smooth Streaming.
Live transcription (preview)
Live transcription is a feature you can use with live events that are either pass-through or live encoding. For more information, see live transcription. When this feature is enabled, the service uses the Speech-To-Text feature of Cognitive Services to transcribe the spoken words in the incoming audio into text. This text is then made available for delivery along with video and audio in MPEG-DASH and HLS protocols.
Currently, live transcription is available as a preview feature in West US 2.
Security considerations for closed captions, subtitles, and timed-metadata delivery
The dynamic encryption and DRM features of Azure Media Services has limits to consider when attempting to secure content delivery that includes live transcriptions, captions, subtitles, or timed-metadata. The DRM subsystems, including PlayReady, FairPlay, and Widevine do not support the encryption and licensing of text tracks. The lack of DRM encryption for text tracks limits your ability to secure the contents of live transcriptions, manual inserted captions, uploaded subtitles, or timed-metadata signals that may be inserted as separate tracks.
To secure your captions, subtitles, or timed-metadata tracks, it is recommended to follow one of the guidelines:
- Use AES-128 Clear Key encryption. When enabling AES-128 clear key encryption, the text tracks can be configured to be encrypted using a full "envelope" encryption technique that follows the same encryption pattern as the audio and video segments. These segments can then be decrypted by a client application after requesting the decryption key from the Media Services Key Delivery service using an authenticated JWT token. This method is supported by the Azure Media Player, but may not be supported on all devices and can require some client-side development work to make sure it succeeds on all platforms.
- Use CDN token authentication to protect the text (subtitle, captions, metadata) tracks being delivered with short form tokenized URLs that are restricted to geo, IP, or other configurable settings in the CDN portal. Enable the CDN security features using Verizon Premium CDN or other 3rd-party CDN configured to connect to your Media Services streaming endpoints.
If you do not follow one of the guidelines above, your subtitles, captions, or timed-metadata text will be accessible as un-encrypted content that could be intercepted or shared outside of your intended client delivery path. This can result in leaked information. If you are concerned about the contents of the captions or subtitles being leaked in a secure delivery scenario, reach out to the Media Services support team for more information on the above guidelines for securing your content delivery.
Live streaming workflow
To understand the live streaming workflow in Media Services v3, you have to first review and understand the following concepts:
In your Media Services account, make sure the streaming endpoint (origin) is running.
Create a live event.
When creating the event, you can specify to autostart it. Alternatively, you can start the event when you are ready to start streaming.
When autostart is set to true, the Live Event will be started right after creation. The billing starts as soon as the Live Event starts running. You must explicitly call Stop on the live event resource to halt further billing. For more information, see live event states and billing.
Get the ingest URL(s) and configure your on-premises encoder to use the URL to send the contribution feed.
See recommended live encoders.
Get the preview URL and use it to verify that the input from the encoder is actually being received.
Create a new asset object.
Each live output is associated with an asset, which it uses to record the video into the associated Azure blob storage container.
Create a live output and use the asset name that you created so that the stream can be archived into the asset.
Live Outputs start on creation and stop when deleted. When you delete the Live Output, you are not deleting the underlying asset and content in the asset.
Create a streaming locator with the built-in streaming policy types.
To publish the live output, you must create a streaming locator for the associated asset.
List the paths on the streaming locator to get back the URLs to use (these are deterministic).
Get the hostname for the streaming endpoint (Origin) you wish to stream from.
Combine the URL from step 8 with the hostname in step 9 to get the full URL.
If you wish to stop making your live event viewable, you need to stop streaming the event and delete the streaming locator.
If you are done streaming events and want to clean up the resources provisioned earlier, follow the following procedure.
- Stop pushing the stream from the encoder.
- Stop the live event. Once the live event is stopped, it will not incur any charges. When you need to start it again, it will have the same ingest URL so you won't need to reconfigure your encoder.
- You can stop your streaming endpoint, unless you want to continue to provide the archive of your live event as an on-demand stream. If the live event is in stopped state, it will not incur any charges.
The asset that the live output is archiving to, automatically becomes an on-demand asset when the live output is deleted. You must delete all live outputs before a live event can be stopped. You can use an optional flag removeOutputsOnStop to automatically remove live outputs on stop.
See Live streaming tutorial, the article examines the code that implements the steps described above.
Other important articles
- Recommended live encoders
- Using a cloud DVR
- Live event types feature comparison
- States and billing
- Quotas and limits
Live streaming FAQ
See the live streaming questions in the FAQ.