Ronald van der Plas · Jul 6, 2026
Automatically transcribing Sitecore Content Hub videos with Azure AI Video Indexer
Video accessibility is one of those topics that sounds simple until you need to support it at scale. For a single video, creating subtitles manually is manageable. For a larger video library, the process quickly becomes repetitive and error-prone. Someone needs to download the video, send it to a transcription service, wait for the results, upload the subtitle file, add the correct metadata, link it to the original video, and make sure it is ready for publishing. That is exactly the kind of process I like to automate. In this post, I want to walk through an architecture for automatically transcribing videos from Sitecore Content Hub with Azure AI Video Indexer. The implementation started with a Sitecore-provided C# coding sample. That sample demonstrated the core integration flow. I then refactored and extended it into a more production-oriented implementation with Azure Functions, queue-based throttling, callback handling and a clearer separation between Content Hub, Azure AI Video Indexer and the integration layer. The goal is simple: Take a video asset from Sitecore Content Hub, generate subtitles with Azure AI Video Indexer, and store the generated subtitle back in Content Hub as a managed asset related to the original video. This is not AI for the sake of AI. It is a practical DAM automation that improves accessibility and removes manual work from the content process. The problem Sitecore Content Hub is a great place to manage video assets, metadata, renditions, relations and publishing workflows. But subtitles often still end up as a separate process. That separation creates a few problems. The challenge is that manual subtitle creation does not scale well. Someone has to manage the transcription process outside of the DAM, which already introduces extra work and coordination. On top of that, different people may create and upload subtitles in different ways, using different naming conventions, metadata structures and storage locations. That may be manageable for a handful of videos, but once you are dealing with hundreds or thousands of existing assets, the process quickly becomes inconsistent, hard to govern and difficult to maintain. The solution The solution starts with a simple idea: use Content Hub as the starting point, let Azure AI Video Indexer do the transcription work, and bring the generated SRT file back into Content Hub as a managed asset. A video in Content Hub already has metadata, renditions, lifecycle state and relationships to other assets or content. If subtitles are generated outside of that model and stored somewhere else, the result is disconnected from the DAM. That is what I wanted to avoid. The Azure Function acts as the orchestration layer between Content Hub and Azure AI Video Indexer. It finds the video in Content Hub, submits it for transcription, and handles the result when Video Indexer is done. When a video needs subtitles, the Function looks for the MP4 rendition. That rendition is used deliberately. The original video file can be very large, and sending that file to Azure AI Video Indexer would increase data transfer, processing time, and potentially cost. The MP4 rendition provides a more controlled version of the video that is still suitable for analysis. Azure AI Video Indexer downloads the MP4 rendition and uses both the audio and visual information to generate the transcription. The Function only passes the rendition URL, so it does not need to temporarily download, store and re-upload the video itself. Because video indexing can take time, the process is asynchronous. After submission, the workflow continues when Azure AI Video Indexer calls the configured callback endpoint. From that callback, the Function uses the original Content Hub asset identifier to connect the result back to the source video, downloads the generated SRT file, and uploads it into Content Hub as a related subtitle asset. The value is in closing the loop: the video starts in Content Hub, Azure AI Video Indexer generates the transcription, and the resulting SRT returns to the managed asset model. Two lanes: bulk and priority For bulk processing, the integration uses an Azure Storage Queue. Existing video libraries can contain hundreds or thousands of assets, so sending everything directly to Azure AI Video Indexer would be risky. The queue gives control over throughput, and a scheduled Azure Function can process the work at a safe pace. Single assets can take a different path. When an editor needs subtitles for a video that is about to be published, that asset should not have to wait behind a large archive backfill. For that scenario, the integration supports a priority lane that submits the video directly to Azure AI Video Indexer. The queue is the safe path for bulk processing. The priority lane is the fast path for urgent single-asset processing. It may bypass the waiting queue, but it should never bypass validation, logging, duplicate detection or state tracking. Important caveat: idempotency One important production caveat is idempotency. A queue helps to control throughput, but it does not automatically prevent duplicate work. The same video can still be triggered multiple times through bulk processing, manual actions or retries. To handle that, the integration should keep a small technical job state outside of Content Hub. In this case, Azure Table Storage is a good fit: it is simple, fast and enough to track whether a transcription job already exists for a specific asset, language and indexing preset. That gives the integration a quick decision point before adding work to the queue or submitting a video to Azure AI Video Indexer. The queue remains responsible for transport and throttling, while Table Storage helps prevent duplicate processing. Do not turn Content Hub into a workflow log The job state is important, but that does not mean every technical status update should be written back to Content Hub. During a large backfill, constantly updating assets with statuses like queued, submitted, processing or retrying would create unnecessary API traffic. It would also make Content Hub responsible for the technical orchestration state, which is not the role I want it to play in this architecture. Content Hub should be updated when there is a meaningful content outcome: the generated SRT asset is created, related to the original video and moved into the right lifecycle state. The detailed processing state belongs in Azure Table Storage and Application Insights. Content Hub should contain the managed result, not every internal step of the integration. Closing thoughts The core API flow is only one part of this solution. The real architectural value is in the operational choices around it: how to process large video libraries safely, how to let urgent assets jump the queue, how to prevent duplicate work, and how to avoid unnecessary pressure on Content Hub. That separation of responsibilities is what makes the architecture practical. Content Hub manages the assets, metadata, lifecycle and relations. Azure AI Video Indexer generates the transcription. Azure Functions orchestrate the workflow. Azure Storage Queue controls bulk throughput. Azure Table Storage helps with idempotency and fast decision-making. At the same time, Content Hub users should still have visibility. For a bulk transcription run, the Azure Function could create a Content Hub task that shows the functional progress to editors and asset managers. That task is for visibility only. The actual orchestration remains in Azure, where the queue, Table Storage and Functions control the workflow. That is where a simple API integration becomes a reliable content workflow: practical, targeted and useful. Not a generic AI demo, but a focused automation that improves accessibility, reduces manual work and fits naturally into the Sitecore Content Hub ecosystem.
Read post →