Microsoft Stream video delivery and network overview
Adaptive bitrate streaming
There are numerous 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 will stream 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 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 video uploaded 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 uses a function to measure the characteristics of the uploaded video and comes up with a recommended bitrate for a 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 are 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 1: This high motion video with a 1080p starting resolution was encoded with 6 renditions and higher bitrates per each rendition.
Example 2: This meeting recording video with mostly static text and a 720p starting resolution was encoded with 5 renditions and much lower bitrates per each rendition.
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 - 3.5Mbps
- 540p - 2.2Mbps
- 396p - 1.4Mbps
- 288p - 850 Kbps
- 216p - 550 Kbps
- 192p - 200 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 - 2.2 Mbps 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, the user's available bandwidth, and the size of the player.
If you want to do some bandwidth estimations, you need to upload some representative videos of the kinds of 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 will be consumed by the number of users you anticipate watching 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:
Leverage existing cache proxies in your network
Playback of videos from Stream is over HTTPS therefore normal web cache proxies can be configured to cache the video playback traffic. There may need to do custom SSL certification configuation 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 playback 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.
Use a 3rd party eCDN video delivery solution optimized for Stream
Several video delivery eCDN solutions are pre-integrated and can be setup 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:
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.
This XML file is updated as the IP addresses for Azure data centers change. Each node in the XML file corresponds to a specific data center: https://www.microsoft.com/download/confirmation.aspx?id=41653
To find the Azure data center for your Stream 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 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="18.104.22.168/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.
Source code on Github: https://github.com/omartin2010/AzureRange
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 drop 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:
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.
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.
The Stream video player then uses the decryption key to decrypt the video on the fly as the video is being played.