Microsoft Stream (Classic) will be retired February 15, 2024 and replaced by Stream (on SharePoint). It is recommended to start using Stream (on SharePoint) by uploading videos to SharePoint, Teams, Yammer, or OneDrive. Functionality in Stream (Classic) will be changed and removed leading up to the retirement date. Learn more...
Microsoft Stream (Classic) 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 (Classic) 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 (Classic) 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 (Classic) determines how many different video qualities or renditions should be created for the uploaded video. Stream (Classic) 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 (Classic) 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 (Classic) measures the characteristics of the uploaded video then recommends bitrate for each rendition. Each video uploaded to Stream (Classic) 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 (Classic) player, click the Gear icon and then select Quality.
|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 (Classic) 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
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 (Classic) 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 (Classic) 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 (Classic) 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 (Classic) 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:
Leverage existing cache proxies in your network
Watching videos from Stream (Classic) 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 (Classic) uses to stream the video for your organization (URLs can vary by Stream (Classic) 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.
Use a third-party eCDN video delivery solution optimized for Stream (Classic)
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 (Classic) endpoints
Microsoft Stream (Classic) requires connectivity to the internet. All endpoints listed on Office 365 endpoints for Microsoft Stream need to be reachable by users of Microsoft Stream (Classic) 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 (Classic) from your encoder, you'll need the following IP ranges and ports open in your network's firewall:
- 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 (Classic) 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 (Classic) tenant:
In Stream, click ? in the upper right corner.
Select About Microsoft Stream.
View the information in Your data is stored in.
After you find out the Azure data center for your Stream (Classic) 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.
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="184.108.40.206/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 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.
Source code on GitHub: https://github.com/omartin2010/AzureRange
CDN used for video playback
Live events from Stream (Classic) and External app or device live events from Yammer/Teams as well as on-demand videos will automatically use Azure CDN.
On-demand videos uploaded to Stream—as well as Live event recordings—will also use Azure CDN for playback, if required. When Azure CDN is not required for these videos, they would be played back from the Azure Media Services origin servers associated with the tenant's geographic region.
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 (Classic) 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.
Video level encryption and playback flow
Stream (Classic) 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:
Stream (Classic) determines if the viewer has access to the video by checking the permissions set on the video in Azure SQL database for Stream (Classic) and information in Azure Active Directory about the user
If the user is allowed to view the video the decryption key is fetched from Azure Media Services and given to the Stream (Classic) video player
The Stream (Classic) video player then uses the decryption key to decrypt the video on the fly as the video is being played