Microsoft Stream video delivery and network overview

Adaptive bitrate streaming

There are many supported video formats that can be uploaded to Microsoft Stream. Each video file is then encoded to a standard format with several different video qualities and sizes for playback. Stream uses HTTPS unicast adaptive bitrate streaming (ABR) to dynamically select the best video playback quality based on the available network bandwidth and size of the video player.

During playback, the player adapts to fluctuations in network conditions and size of the player. When the available bandwidth is high, the player streams a high-quality version of the video. When the bandwidth drops, the player streams a low-quality version of the video. The quality and resolution of the video will also be proportional to the size of the player. If a viewer is watching on a smaller screen, they'll always get a smaller version of the video.

The adaptive bitrate streaming does all this work in the background while the video plays with the least amount of disruption or buffering. During video playback, the video player lets the viewer to manually override the automatic playback quality, to select a specific video playback quality.

Smart encoding of uploaded videos for adaptive bitrate streaming

Stream uses some smarts to determine how it creates the different video qualities and sizes from the original uploaded video to be used for adaptive bitrate streaming.

First, Stream determines how many different video qualities or renditions should be created for the uploaded video. Stream takes into consideration the original resolution of the video. For example, if it's a 1080p or higher video it will create more quality levels (about 6) to step down to the lowest quality version. If instead the uploaded video is 480p, it will create fewer quality levels (about 3) to step down to the lowest quality version. Stream won't generate a resolution of the video that exceeds the resolution of the originally uploaded video.

After the number of video qualities or renditions is decided, the next stage is to determine the bitrate for each rendition. The higher the quality of the rendition the more bits it requires. However not all videos are created equal, different types of videos require different bitrates to achieve a high quality viewing experience. If a video has lots of motion, it will need to be delivered with a higher bitrate to achieve a great viewing experience. However, a PowerPoint presentation in a video with mostly static text can still get a great viewing experience at a lower bitrate.

To address this variability in video content, Stream measures the characteristics of the uploaded video then recommends bitrate for each rendition. Each video uploaded to Stream will end up with a slightly different set of resolutions and bitrates used for streaming, to ensure that we're using bandwidth wisely and only using more bits when it's needed.

When viewing a video on Stream, the different renditions that were created for adaptive bitrate streaming can be seen in the player:

  • In the Stream player, click the Gear icon and then select Quality.
Example      Description Player                    
Teams meeting recordings Teams meeting recordings are encoded with a single 1080p resolution video rendition. 1080p – 574 Kbps
Video-on-demand (excluding meeting recordings) Non-Teams video-on-demand is encoded with a content-aware preset that intelligently selects up to 6 video renditions, as shown in this example. Higher complexity content with a high degree of color and motion variance will be encoded with more video renditions and lower complexity content will be encoded with fewer. 1080p – 3 Mbps
720p – 1.6 Mbps
540p – 989 Kbps
360p – 460 Kbps
270p – 327 Kbps
180p – 193 Kbps

Encoding profile for live events

The smart encoding listed above only applies to videos uploaded to Stream.

Live events created in Stream or "External app or device" produced live events from Yammer or Microsoft Teams will get a fixed encoding profile:

  • 720p - 1.7 Mbps
  • 540p - 850 Kbps
  • 360p - 350 Kbps
  • 240p - 140 Kbps

Note

If your input video resolution from the encoder is 720p or higher you'll get the above profile. If you drop your input video resolution from the encoder to lower than 720p, then you'll only get output bitrates from your input resolution and down. For example, if you sent 540p resolution from your encoder then the highest bitrate viewers would be able to get is the 540p - 850kbps version. Stream does not change the above live encoding profile based on input bitrate from the encoder, it only cuts off quality levels based on input resolution.

Bandwidth requirements for video playback

Video playback in Stream is unicast, meaning every viewer is getting their own video stream from the internet. Based on the smart encoding and adaptive bitrate streaming used by Stream, the bandwidth requirement for video playback isn't a static number. Playing a video can consume different amounts of internet bandwidth, depending on an uploaded video's:

  • original resolution, bitrate, and content
  • user's available bandwidth
  • size of the player

If you want to develop some bandwidth estimations, you need to upload some videos that represent the typical content your organization will use with Stream and watch the videos on screen sizes you think will be used by your users. You can then do some bandwidth measurements and sampling. You could then use these approximations to make some high-level calculations and estimates of how much bandwidth your users will consume based on how many you think will watch videos at the same time.

Optimizing video delivery within my local network

Stream leverages the smart encoding and adaptive bitrate streaming to reduce network and internet traffic of video playback. However playback is a unicast stream. For live events or videos sent out to large portions of your organization, there could be a significant amount of internet bandwidth consumed by viewers.

For organizations that want to reduce this internet traffic for live events and popular videos, there are two options:

  1. Leverage existing cache proxies in your network

    Watching videos from Stream happens over HTTPS therefore, normal web cache proxies can be configured to cache the video playback traffic. You may need to configure custom SSL certification to make this happen with HTTPS. However, if you look at a network trace while playing a video, you can see the URLs that Stream uses to stream the video for your organization (URLs can vary by Stream tenant). If you route those URLs through your cache proxy, it can cache the video traffic and reduce your internet traffic for often played videos.

  2. Use a third-party eCDN video delivery solution optimized for Stream

    Several video delivery eCDN solutions are pre-integrated and can be set up to be used with Stream. These eCDN platforms enable organizations to optimize network bandwidth without sacrificing end user viewing experiences. Our partners can help enable a more scalable and efficient video distribution across your enterprise network. See Scaling video delivery with 3rd party eCDN providers for more information.

Endpoints that need to be reachable by users inside your network

General Microsoft Stream endpoints

Microsoft Stream requires connectivity to the internet. All endpoints listed on Office 365 endpoints for Microsoft Stream need to be reachable by users of Microsoft Stream within your organization's network.

External app or device produced live events (formerly external encoder) - RMTP ingest endpoints

To get a video feed for an External app or device produced live event sent to Microsoft Stream from your encoder you'll need the following IP ranges and ports open in your network's firewall or proxy:

  • Domains: *.channel.media.azure.net
  • Ports: 1935/2935/1936/2936 (for RTMP and RTMPS)

If your specific network setup doesn't allow you to (or you don't want to) open up the domain range above, currently the only option to get specific IP addresses for the RTMP/RTMPS ingest, is to get the rotating IP ranges for the Azure data center that your Microsoft Stream tenant is connected to.

The following JSON files are updated as the IP addresses for Azure data centers change, broken own by region and by the tagged services.

These files are updated weekly and include versioning both for the full file and each individual service tag in that file.

To find the Azure data center for your Stream tenant:

  1. In Stream, click ? in the upper right corner.

  2. Select About Microsoft Stream.

  3. View the information in Your data is stored in.

After you find out the Azure data center for your Stream tenant, find the corresponding IP ranges in the XML file above, and then update your firewall/proxy with the specific IP ranges for your data center. As the XML file changes you'll need to update your firewall/proxy settings as well.

Example:

  • If About Microsoft Stream says that your data is stored in "East US 2"

  • In the XML file, you would look for a node labeled <Region Name="useast2">

  • Under that Region node, there would be several entries for all the IP ranges (<IpRange Subnet="13.68.0.0/17">)

  • You would need to configure your firewall\proxy to allow all of these IP ranges and change them on a regular basis when the XML file changes.

Users in the community have written code that on a schedule it takes the XML file above and converts the data into an API that can be queried. Your organization my be able to learn from what was done with this open source project and build your own similiar solution to regularly update your firewall/proxy settings.

General Microsoft Stream endpoints

Microsoft Stream requires connectivity to the internet. All endpoints listed on Office 365 endpoints for Microsoft Stream need to be reached by Microsoft Stream users within your organization's network.

Reaching viewers when you have a VPN split-tunneling configuration

For customers who connect their remote worker devices to the corporate network or cloud infrastructure over VPN, Microsoft recommends that streaming video for Microsoft 365 live events is routed over a VPN split tunnel configuration. This method becomes especially important as a first-line strategy to ensure continued employee productivity during large-scale work-from-home events such as the COVID-19 crisis.

Tip

Microsoft recommends focusing split-tunnel VPN configuration on documented dedicated IP ranges for Office 365 services. FQDN or AppID-based split tunnel configurations, while possible on certain VPN client platforms, may not fully cover key Office 365 scenarios and may conflict with IP-based VPN routing rules. For this reason, Microsoft does not recommend using FQDNs to configure split-tunnel VPN. The use of FQDN configuration may be useful in other related scenarios, such as .pac file customizations or to implement proxy bypass.
Tip borrowed from Office 365 Enterprise

To allow video streams from Microsoft 365 live events to reach playback endpoints without congesting your VPN, customers without explicit proxies can use a set of static IP addresses to split-tunnel live event traffic. You'll need port 443 open for the following Azure CDN IP addresses in your network's VPN split-tunneling configuration.

IPv4 IPv6
72.21.81.200 2606:2800:011F:17A5:191A:18D5:0537:22F9
152.199.19.161 2606:2800:133:206E:1315:22A5:2006:24FD
117.18.232.200 2606:2800:0147:120F:030C:1BA0:0FC6:265A
192.16.48.200 2606:2800:0157:1508:1539:0174:1A75:1191
93.184.215.201 2606:2800:11F:7DE:D31:7DB:168F:1225
68.232.34.200 2606:2800:133:F17:19E8:2356:251B:02A9
192.229.232.200 2606:2800:0147:0FF8:129B:22EB:020B:1347

Note

The above guidance will not be helpful for customers with a VPN+proxy configuration. Microsoft is working on a solution for such scenarios.

External app or device produced live events (formerly external encoder) - RMTP ingest endpoints

To get a video feed for an External app or device produced live event sent to Microsoft Stream from your encoder, you'll need the following IP ranges and ports open in your network's firewall or proxy:

  • Domains: *.channel.media.azure.net

  • Ports: 1935/2935/1936/2936 (for RTMP and RTMPS)

If your specific network setup doesn't allow you to (or you don't want to) open up the domain range above, currently the only option to get specific IP addresses for the RTMP/RTMPS ingest, is to get the rotating IP ranges for the Azure data center that your Microsoft Stream tenant is connected to.

The following JSON files are updated as the IP addresses for Azure data centers change, broken own by region and by the tagged services.

Public: https://www.microsoft.com/en-us/download/details.aspx?id=56519 US Gov: <https://www.microsoft.com/en-us/download/details.aspx?id=57063 Germany: https://www.microsoft.com/en-us/download/details.aspx?id=57064 China: https://www.microsoft.com/en-us/download/details.aspx?id=57062

These files are updated weekly and include versioning both for the full file and each individual service tag in that file.

To find the Azure data center for your Stream tenant:

  1. In Stream, click ? in the upper right corner

  2. Select About Microsoft Stream

  3. View the information in the Your data is stored in section

After you find out the Azure data center for your Stream tenant, find the corresponding IP ranges in the XML file above, and then update your firewall/proxy with the specific IP ranges for your data center. As the XML file changes you'll need to update your firewall/proxy settings as well.

Example:

  • If About Microsoft Stream says that your data is stored in "East US 2"

  • In the XML file, you would look for a node labeled ()

  • Under that Region node, there would be several entries for all the IP ranges ()

  • You would need to configure your firewall\proxy to allow all of these IP ranges and change them on a regular basis when the XML file changes.

Users in the community have written code that, on a schedule, it takes the XML file above and converts the data into an API that can be queried. Your organization may be able to learn from what was done with this open-source project and build your own similar solution to regularly update your firewall/proxy settings.

CDN used for video playback

Live events from Stream and External app or device live events from Yammer/Teams will automatically use Azure CDN.

If several people from the same organization within the same geographic location are streaming the same video(s), CDNs will store a copy of these videos in a location closer to that geographic region. With the video stored, or cached at the closest location, each person streams the video from the location closest to them instead of a location further away. Stream uses Azure Media Services to manage what is cached in the Azure CDNs, and for how long. Azure Media Services can use any of the Azure CDN locations to cache video fragments and manifests for a few days. If people in your organization continue to watch the cached videos they'll stay in the cache. If no one accesses the video for several days, the video will eventually be dropped from the cache. The next time someone attempts to watch the video it’s once again cached at the nearest CDN location.

Everyone who attempts to watch the video while the content is cached at a nearby CDN, benefits from the video being closer, and in most cases, less hops, away. This improves video playback speed; however, it doesn’t change the network requirement to play the video.

On-demand videos uploaded to Stream don't yet use Azure CDN for playback. Non-live videos in Stream are played back from the Azure Media Services origin server associated with your tenant in your tenant's geographic region.

Video level encryption and playback flow

Stream knows how important it is to keep your data secure and private. The Microsoft Trust Center describes our commitment to the privacy and security of your content. With video playback, speed is important for a good experience; however, we don’t compromise your security or privacy in exchange for speed. Here’s how we accommodate speed, security and privacy.

When you or someone in your organization uploads a new video or creates a live event, that video is transcoded, encrypted with AES-128 encryption, and stored in Azure Media Services. This means the videos are encrypted both in transit and at rest.

When someone in your organization attempts to watch a video, they follow these steps:

  1. Stream determines if the viewer has access to the video by checking the permissions set on the video in Azure SQL database for Stream and information in Azure Active Directory about the user

  2. If the user is allowed to view the video the decryption key is fetched from Azure Media Services and given to the Stream video player

  3. The Stream video player then uses the decryption key to decrypt the video on the fly as the video is being played

See also

Scaling video delivery with 3rd party eCDN providers