Microsoft Azure is the cloud service offered by Microsoft that competes with other leading cloud providers like AWS and Google Cloud. It provides access to data centers and services managed by Microsoft.

Similar to the popular AWS S3 storage, Azure provides an object storage called Azure Blob Storage. Users can upload images, videos, documents, zip files, and more without worrying about storage space, which is practically infinite.

In this post we'll look at how to stream videos with Azure Blob Storage in 2026, why the standard "use Azure Media Services" advice no longer applies, and how to get adaptive bitrate streaming, format optimization, and real-time transformations by attaching ImageKit to your existing Blob Storage container.

For this demonstration, we have uploaded a 14.7 MB sample MP4 video test-video.mp4 to a container called test-public in our Azure Blob Storage account.

We can generate a Shared Access Signature (SAS) URL in Azure to provide access to this video file directly from the blob storage. The SAS URL can then be used directly on your website or app to load the video:

<video controls>
  <source src="https://storageaccountname.blob.core.windows.net/test-public/test-video.mp4?sp=r&sv=2026-02-06&sr=b&sig=<signature>..." type="video/mp4" />
</video>

When you load this video URL on an HTML page, the browser issues multiple range requests to access the file in smaller chunks. The response status code for each request is 206, indicating a partial response from the server that matches the browser's requested segment.

Direct Blob Storage delivery gives you progressive MP4 playback via HTTP range requests, which works as a baseline. It is not, however, what services like YouTube and Netflix do. Those use adaptive bitrate streaming, where a larger video file is broken into smaller chunks encoded at different bitrates. A manifest file describes the available chunks. A video player then decides which chunk to load and at what resolution based on the viewer's device and network conditions. That's the adjustment in quality you've probably seen on YouTube when your connection slows down.

Without adaptive bitrate, viewers on slow networks see buffering. Viewers on fast networks see a single quality regardless of their device. Progressive MP4 delivery can be acceptable for small clips, but it gives every viewer the same encoded file. That means slower networks may buffer, mobile users may receive more data than needed, and you do not get automatic quality switching. For anything beyond simple internal clips, you need a real streaming pipeline on top of Blob Storage.

For years, Microsoft's recommended path was Azure Media Services. You stored original video in Blob Storage, used Media Services to encode the video into HLS or DASH manifests, and delivered through a Media Services streaming endpoint.

Microsoft retired Azure Media Services on June 30, 2024. Azure Media Player retired with it. The official Azure Media Services Migration Tool that Microsoft published as a fallback was archived in May 2025 and is no longer maintained.

Microsoft's current guidance points customers to a small list of third-party partners (Bitmovin, MediaKind, Ravnur are the prominent ones) or to a build-it-yourself path using Azure Functions or AKS with FFmpeg. Each partner has its own opinions about how your video infrastructure should work, and most require re-ingesting assets, generating derivatives outside your current Blob workflow, or changing how playback URLs are managed. The DIY path means owning an encoding pipeline, ABR ladder design, manifest generation, CDN configuration, player integration, and DRM. A baseline VOD pipeline using Azure Functions, FFmpeg, Front Door, and a third-party player runs about four to six weeks of senior engineering work to get to production, plus ongoing maintenance.

There is a third option that doesn't appear in Microsoft's guide: attach your existing Blob Storage to ImageKit and let ImageKit's URL-based video API handle the streaming pipeline. Your videos stay where they are and the setup takes about fifteen minutes.

Connecting Azure Blob Storage to ImageKit

ImageKit is a real-time media optimization, transformation, and management platform that natively integrates with popular cloud storages including Azure Blob Storage, whether private or public. Once attached, ImageKit's URL endpoint becomes a transformation and delivery layer in front of your storage.

Read more on configuring external storage with ImageKit.

ImageKit does not move or copy any content from your Blob Storage. The integration provides on-demand access to the original file when a request comes in. The first request triggers any required encoding or transformation, and the result is cached at the CDN edge for subsequent requests.

Streaming optimized video with ImageKit and Azure Blob Storage

With our storage attached to ImageKit, we can access our video at:

https://ik.imagekit.io/ikmedia/videodemo/test-video.mp4

When you load a video using this URL, ImageKit automatically identifies the requesting device and its video format support to deliver the video in WebM (VP9 or AV1 codecs) or MP4 (H264), the two most widely used web-safe video formats. ImageKit also compresses the video in near real time without significantly degrading its visual quality.

These optimizations are dashboard settings, not code. Turn them on once and ImageKit handles the rest when you deliver video through its URL.

When we deliver our 14.7 MB sample video through ImageKit, it goes from 14.7 MB to 9.1 MB when compressed and delivered as WebM in Chrome. No encoding job to run, no manifest to generate, no setup beyond the storage attachment.

Transforming videos for different use cases

ImageKit offers a URL-based real-time video API, making it easy to adapt videos to different devices and placements. You can resize, crop, watermark, generate snippets, or generate thumbnails in real time. These transformations help you deliver a complete video experience on the client device without external products or custom code.

To scale our video to 200px width, add the transformation parameter tr=w-200 to the URL:

https://ik.imagekit.io/ikmedia/videodemo/test-video.mp4?tr=w-200

ImageKit still applies format and quality optimization while resizing. The video gets compressed to 184 KB and is delivered as WebM.

For vertical formats like Instagram Reels or TikTok-style content, specify both height and width. ImageKit handles the cropping in real time and returns the requested aspect ratio. For a 400 by 640 vertical video:

https://ik.imagekit.io/ikmedia/videodemo/test-video.mp4?tr=w-400,h-640

The output is 2.3 MB.

For a deeper look at video cropping and resizing with ImageKit, see Crop and resize videos in React.

We can also watermark our video and control placement and formatting in real time. The example below uses ImageKit's layers syntax to overlay a logo image on the underlying video. You can also overlay text or another video on top of the base. No extensive setup. A URL change does it.

https://ik.imagekit.io/ikmedia/videodemo/test-video.mp4?tr=w-400,h-640,l-image,i-logo_HuFO6vJ2x.png,lx-10,ly-10,w-200,l-end

All of these transformations work without a specific player like Video.js. You can load the resulting URLs directly in a <video> tag and the browser will play them.

Adaptive bitrate streaming with Azure Blob Storage and ImageKit

Adaptive bitrate streaming encodes videos at different bitrates and resolutions and switches between them based on the viewer's network and device. All popular streaming services use it, and it's the central capability that disappeared from the Azure stack when Media Services retired.

ImageKit makes DASH and HLS available as URL parameters. As with everything else in the platform, you don't run encoding jobs or manage manifest files. You modify the URL.

For an HLS stream at 360p, 480p, and 720p:

https://ik.imagekit.io/ikmedia/videodemo/test-video.mp4/ik-master.m3u8?tr=sr-360_480_720

For DASH, swap ik-master.m3u8 for ik-master.mpd. The same source URL produces both protocols on demand.

When the URL is requested for the first time, ImageKit starts transcoding the video to the requested resolutions in the background, and if the processing takes long, the first request for a manifest may return a 202 response. It stores the manifest file and segment chunks internally and serves them from the CDN on subsequent requests after all transcoding is complete.

For production workflows, trigger the ABS URL during upload/publish, listen for the webhook, and expose the player only after the video.transformation.ready event. This way, you avoid the 202 response and ensure a smooth experience for the first viewer.

You can load the manifest URL directly in any HLS-capable player. Safari supports HLS playback natively. For Chrome, Firefox, and Edge, use a JavaScript player such as Video.js, hls.js, or ImageKit's Video Player SDK. DASH usually requires a player such as Shaka Player or dash.js.

In the network panel of any browser, you can watch the player request a 360p segment first for fast initial load, then switch to 720p once the player determines the device and connection support it.

Webhooks for transcoding completion

Generating manifests and segments at multiple resolutions takes time on the first request. To improve the development experience and provide certainty about when an asset is ready, ImageKit offers video webhooks that fire on transcoding completion:

{
  "type": "video.transformation.ready",
  "id": "a03031b5-ad5f-4985-8cf5-4de67630f6d7",
  "created_at": "2026-04-15T12:00:11.703Z",
  "request": {
    "x_request_id": "fa98fa2e-d6cd-45b4-acf5-bc1d2bbb8ba9",
    "url": "https://ik.imagekit.io/ikmedia/videodemo/test-video.mp4/ik-master.m3u8?tr=sr-360_480_720",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0"
  }
}

Webhooks are optional. The transcoding process described above works the same whether or not you subscribe to them.

No re-processing required when delivery requirements change

One of the operational costs of a traditional encoding pipeline is that changes to delivery requirements (a new watermark, a new aspect ratio, a new resolution tier) require re-running encoding jobs across your entire back catalog. That cost compounds as your library grows.

With ImageKit, requirement changes are URL changes. You modify the transformation parameters and the new variant is generated on the next request and cached at the edge. Videos that aren't requested are never processed. Videos that need an updated transformation get it the first time someone asks for it.

For a team migrating off Azure Media Services and worried about the operational overhead of running encoding jobs going forward, this is the piece that disappears entirely.

Conclusion

Azure Blob Storage continues to operate normally. Customer videos and associated assets in Blob Storage were unaffected by the Azure Media Services retirement. What disappeared was the layer on top: encoding, packaging, the streaming endpoints, and the SDK that turned stored video into a streaming experience.

Microsoft's official guidance now points to third-party partners or a DIY pipeline. There's a third option: keep your videos in Blob Storage and attach the container to ImageKit as an origin. The setup takes about fifteen minutes. From that point, every video in your container is streamable through ImageKit's URL endpoint, with HLS or DASH adaptive bitrate, format optimization, real-time transformations, watermarking, and webhook notifications, all configured as URL parameters or dashboard settings.

ImageKit's free plan includes 500 seconds of SD video processing and 20 GB of streaming bandwidth per month, which is enough to validate the approach against your real content before committing.

Sign up for a free ImageKit account and try it against an existing video in your Blob Storage container.

If your videos are on a different cloud provider, the same approach works for AWS S3 and Google Cloud Storage.