Overview of Live Streaming using Media Services

Overview

When delivering live streaming events with Azure Media Services the following components are commonly involved:

• A camera that is used to broadcast an event.

• A live video encoder that converts signals from the camera to streams that are sent to a live streaming service.

  Optionally, multiple live time synchronized encoders. For certain critical live events that demand very high availability and quality of experience, you should employ active-active redundant encoders with time synchronization to achieve seamless failover with no data loss.

• A live streaming service that enables you to do the following:

  • ingest live content using various live streaming protocols (for example RTMP or Smooth Streaming),
  • (optionally) encode your stream into adaptive bitrate stream
  • preview your live stream,
  • record and store the ingested content in order to be streamed later (Video-on-Demand)
  • deliver the content through common streaming protocols (for example, MPEG DASH, Smooth, HLS) directly to your customers, or to a Content Delivery Network (CDN) for further distribution.

Microsoft Azure Media Services (AMS) provides the ability to ingest, encode, preview, store, and deliver your live streaming content.

With Media Services, you can take advantage of dynamic packaging, which allows you to 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.

Streaming Endpoints, Channels, Programs

In Azure Media Services, Channels, Programs, and StreamingEndpoints handle all the live streaming functionalities including ingest, formatting, DVR, security, scalability and redundancy.

A Channel represents a pipeline for processing live streaming content. A Channel can receive a live input streams in the following ways:

• An on-premises live encoder sends multi-bitrate RTMP or Smooth Streaming (fragmented MP4) to the Channel that is configured for pass-through delivery. The pass-through delivery is when the ingested streams pass through Channels without any further processing. You can use the following live encoders that output multi-bitrate Smooth Streaming: MediaExcel, Ateme, Imagine Communications, Envivio, Cisco and Elemental. The following live encoders output RTMP: Telestream Wirecast, Haivision, Teradek transcoders. A live encoder can also send a single bitrate stream to a channel that is not enabled for live encoding, but that is not recommended. When requested, Media Services delivers the stream to customers.

  Note

  Using a pass-through method is the most economical way to do live streaming when you are doing multiple events over a long period of time, and you have already invested in on-premises encoders. See pricing details.

• An on-premises live encoder sends a single-bitrate stream to the Channel that is enabled to perform live encoding with Media Services in one of the following formats: RTMP or Smooth Streaming (fragmented MP4). The following live encoders with RTMP output are known to work with channels of this type: Telestream Wirecast. The Channel then performs live encoding of the incoming single bitrate stream to a multi-bitrate (adaptive) video stream. When requested, Media Services delivers the stream to customers.

Starting with the Media Services 2.10 release, when you create a Channel, you can specify in which way you want for your channel to receive the input stream and whether or not you want for the channel to perform live encoding of your stream. You have two options:

• None (pass-through) – Specify this value, if you plan to use an on-premises live encoder which will output multi-bitrate stream (a pass-through stream). In this case, the incoming stream passed through to the output without any encoding. This is the behavior of a Channel prior to 2.10 release.
• Standard – Choose this value, if you plan to use Media Services to encode your single bitrate live stream to multi-bitrate stream. This method is more economical for scaling up quickly for infrequent events. Be aware that there is a billing impact for live encoding and you should remember that leaving a live encoding channel in the "Running" state will incur billing charges. You should immediately stop your running channels after your live streaming event is complete to avoid extra hourly charges.

Comparison of Channel Types

Following table provides a guide to comparing the two Channel types supported in Media Services

Working with Channels that receive multi-bitrate live stream from on-premises encoders (pass-through)

The following diagram shows the major parts of the AMS platform that are involved in the pass-through workflow.

For more information, see Working with Channels that Receive Multi-bitrate Live Stream from On-premises Encoders.

Working with Channels that are enabled to perform live encoding with Azure Media Services

The following diagram shows the major parts of the AMS platform that are involved in Live Streaming workflow where a Channel is enabled to perform live encoding with Media Services.

For more information, see Working with Channels that are Enabled to Perform Live Encoding with Azure Media Services.

Description of a Channel and its related components

Channel

In Media Services, Channels are responsible for processing live streaming content. A Channel provides an input endpoint (ingest URL) that you then provide to a live transcoder. The channel receives live input streams from the live transcoder and makes it available for streaming through one or more StreamingEndpoints. Channels also provide a preview endpoint (preview URL) that you use to preview and validate your stream before further processing and delivery.

You can get the ingest URL and the preview URL when you create the channel. To get these URLs, the channel does not have to be in the started state. When you are ready to start pushing data from a live transcoder into the channel, the channel must be started. Once the live transcoder starts ingesting data, you can preview your stream.

Each Media Services account can contain multiple Channels, multiple Programs, and multiple StreamingEndpoints. Depending on the bandwidth and security needs, StreamingEndpoint services can be dedicated to one or more channels. Any StreamingEndpoint can pull from any Channel.

When creating a Channel, you can specify allowed IP addresses in one of the following formats: IpV4 address with 4 numbers, CIDR address range.

Program

A Program enables you to control the publishing and storage of segments in a live stream. Channels manage Programs. The Channel and Program relationship is very similar to traditional media where a channel has a constant stream of content and a program is scoped to some timed event on that channel. You can specify the number of hours you want to retain the recorded content for the program by setting the ArchiveWindowLength property. This value can be set from a minimum of 5 minutes to a maximum of 25 hours.

ArchiveWindowLength also dictates the maximum amount of time clients can seek back in time from the current live position. Programs can run over the specified amount of time, but content that falls behind the window length is continuously discarded. The value of this property also determines how long the client manifests can grow.

Each program is associated with an Asset. To publish the program you must create a locator for the associated asset. Having this locator will enable you to build a streaming URL that you can provide to your clients.

A channel supports up to three concurrently running programs so you can create multiple archives of the same incoming stream. This allows you to publish and archive different parts of an event as needed. For example, your business requirement is to archive 6 hours of a program, but to broadcast only last 10 minutes. To accomplish this, you need to create two concurrently running programs. One program is set to archive 6 hours of the event but the program is not published. The other program is set to archive for 10 minutes and this program is published.

Billing Implications

A channel begins billing as soon as it's state transitions to "Running" via the API.

The following table shows how Channel states map to billing states in the API and Azure portal. Note that the states are slightly different between the API and Portal UX. As soon as a channel is in the "Running" state via the API, or in the "Ready" or "Streaming" state in the Azure portal, billing will be active.

To stop the Channel from billing you further, you have to Stop the Channel via the API or in the Azure portal. You are responsible for stopping your channels when you are done with the channel. Failure to stop the channel will result in continued billing.

Channel states and how they map to the billing mode

The current state of a Channel. Possible values include:

• Stopped. This is the initial state of the Channel after its creation (unless autostart was selected in the portal.) No billing occurs in this state. In this state, the Channel properties can be updated but streaming is not allowed.
• Starting. The Channel is being started. No billing occurs in this state. No updates or streaming is allowed during this state. If an error occurs, the Channel returns to the Stopped state.
• Running. The Channel is capable of processing live streams. It is now billing usage. You must stop the channel to prevent further billing.
• Stopping. The Channel is being stopped. No billing occurs in this transient state. No updates or streaming is allowed during this state.
• Deleting. The Channel is being deleted. No billing occurs in this transient state. No updates or streaming is allowed during this state.

The following table shows how Channel states map to the billing mode.