The post Nordic Digital Infrastructure 2026 | Cloud & Enterprise Analysis appeared first on T-21.

The post Nordic Digital Infrastructure 2026 | Cloud & Enterprise Analysis appeared first on T-21.

The post The Complete Guide to IoT Wireless Connectivity in 2026 appeared first on T-21.

The post The Complete Guide to IoT Wireless Connectivity in 2026 appeared first on T-21.

The post Five Enterprise Connectivity Trends Reshaping Infrastructure in 2026 appeared first on T-21.

The post Five Enterprise Connectivity Trends Reshaping Infrastructure in 2026 appeared first on T-21.

For the current generation of AI startups, cloud credits have become the de facto currency of early-stage infrastructure. Accelerator programmes from Y Combinator, Microsoft for Startups, Google for Startups, and AWS Activate routinely distribute credit packages ranging from $50,000 to $350,000 across providers including Azure, Google Cloud, AWS, and increasingly the API platforms of model providers like OpenAI, Anthropic, and Cohere. These credits are meant to give startups runway to build, train, and deploy without upfront infrastructure costs. In theory, the system works. In practice, it is creating a set of problems that few people in the ecosystem are willing to discuss openly.

The credit allocation mismatch

The core issue is straightforward: the credits startups receive rarely match the infrastructure they actually need.

A startup accepted into a major accelerator programme might receive $150,000 in Google Cloud credits and $100,000 in Azure OpenAI credits as part of a standard partner package. But if the founding team has built its stack on AWS Bedrock with Anthropic’s Claude as the primary model, a significant portion of those credits sits unused. The startup cannot transfer them. It cannot combine them. In most cases, it cannot even convert Google Cloud credits into Google Cloud AI API credits for a different service tier within the same provider.

The result is that AI startups across the ecosystem are sitting on tens of thousands of dollars in credits they cannot use, while simultaneously paying full price for the compute they actually need. According to estimates from secondary market participants, more than $2 billion in AI credits expire unused every year across the major cloud providers. For startups operating on eighteen-month runways, that waste is not an abstraction — it is the difference between an additional engineer and an earlier funding round.

What the credits actually cost

The sticker price of AI compute has declined on a per-token and per-GPU-hour basis over the past two years. But the effective cost for startups has not fallen proportionally, for several reasons.

First, the models themselves have become more capable but also more expensive to run at production scale. A startup using GPT-4o or Claude Sonnet for real-time inference in a customer-facing product is spending meaningfully more per request than one that used GPT-3.5 two years ago. The quality improvement justifies the cost in most cases, but it compresses margins and accelerates credit burn.

Second, fine-tuning and evaluation pipelines consume credits at rates that are difficult to predict during the experimentation phase. A team iterating on a retrieval-augmented generation architecture might burn through $20,000 in credits over a two-week sprint without producing a production-ready system. That is an expected part of the development process, but it means that a $100,000 credit package provides less effective runway than founders anticipate when they receive it.

Third, multi-model architectures are becoming standard practice. Startups increasingly use different models for different tasks within the same product — a smaller model for classification, a larger model for generation, a specialised model for code or structured output. Each model may run on a different provider’s infrastructure, multiplying the number of credit accounts that need to be funded and managed.

The secondary market response

The mismatch between credit allocation and credit consumption has created a growing secondary market. Platforms have emerged where startups and enterprises can trade unused credits — selling what they cannot use and buying what they need at discounts that typically range from twenty to forty percent below list price.

For a startup sitting on $150,000 in Google Cloud credits it cannot use, the ability to sell google cloud credits and recover even sixty to seventy percent of the face value represents a meaningful extension of runway. Conversely, for a team that has committed to Google’s ecosystem but exhausted its initial allocation, the option to buy google cloud credits at a significant discount from the secondary market is an obvious efficiency gain.

The model is not dissimilar to what happened in other enterprise software markets as cloud adoption matured. Unused software licences, reserved instance commitments, and prepaid SaaS contracts all eventually developed secondary markets as buyers and sellers recognised the inefficiency of letting paid-for capacity go to waste.

What makes AI credits slightly different is the velocity at which they lose value. Most credit packages expire within twelve to eighteen months. Unlike a reserved EC2 instance that provides predictable compute capacity over a three-year term, an AI credit package is a depreciating asset from the moment it is issued. Every month that passes without using the credits reduces their effective value — not because the credit amount changes, but because the window for extracting value from them narrows.

Provider dynamics and the credit ecosystem

The major cloud and AI providers have complex incentives around the credit ecosystem. On one hand, credits are a customer acquisition tool. Google, Microsoft, Amazon, and the model API providers distribute credits generously because they want startups to build on their platforms, creating long-term lock-in that generates revenue well beyond the initial credit period. On the other hand, unused credits that expire represent recognised revenue without corresponding infrastructure cost — a favourable outcome from a pure financial perspective.

This creates a tension that the providers have not resolved publicly. The official terms of service for most credit programmes prohibit transfer or resale. But enforcement has been inconsistent, and the practical reality is that the secondary market exists and is growing because it solves a genuine problem for both buyers and sellers.

For streaming and media technology companies — the core audience of this publication — the dynamics are particularly relevant. Media AI workloads including automated transcription, content moderation, video understanding, and recommendation systems are among the most compute-intensive applications in production today. A mid-stage media technology startup might be spending $30,000 to $50,000 per month on inference costs alone. At those consumption rates, a twenty to thirty percent discount on credits through secondary channels is not a minor optimisation — it is a material impact on unit economics.

What this means for the market

The AI credit economy is still in its early stages. As the market matures, several things are likely to happen. Credit terms will become more standardised, making them easier to value and trade. Providers may introduce official transfer mechanisms as they recognise that rigid credit allocation discourages multi-cloud adoption without actually preventing it. And startups will become more sophisticated about credit management as a financial discipline — treating compute credits with the same rigour they apply to cash management and equity dilution.

For now, the practical advice for AI startups is simple. Audit your credit portfolio regularly. Know what you have, when it expires, and whether you are actually going to use it. If the answer is no, explore the secondary market before the expiration date turns your credits into a write-off. The compute bill is already one of the largest line items on an AI startup’s P&L. Letting paid-for credits expire unused is one of the few costs that is entirely avoidable.

The post The Hidden Compute Bill: Why AI-First Startups Are Burning Through Credits Faster Than Runway appeared first on T-21.

The post The Hidden Compute Bill: Why AI-First Startups Are Burning Through Credits Faster Than Runway appeared first on T-21.

Sam Cooper is the founder of Flowpast, a consultancy that helps organisations implement AI-driven workflow automation across their operations. Rather than building bespoke AI models, Flowpast focuses on the automation layer — connecting existing tools, eliminating manual process steps, and building the operational infrastructure that allows AI capabilities to deliver value at scale. We spoke with him about why workflow automation is becoming a priority for media and technology organisations, where the biggest efficiency gains are hiding, and what streaming operations teams should consider before investing in another AI tool.

The workflow problem in media operations

T-21: You work with organisations across several industries. What patterns do you see when companies come to you for help with automation?

Sam Cooper: Almost universally, the organisations we work with have already invested in capable tools. They have good encoding platforms, decent monitoring systems, functional content management. The problem is rarely that they lack technology — it is that the technology does not talk to itself. A file lands in an ingest system, someone manually checks the metadata, emails a team to confirm the delivery specification, waits for approval, then triggers the transcode job. Each individual step takes five minutes. But when you chain twenty of those steps together across a content pipeline that handles hundreds of assets per day, you have built a system that runs on human memory and email threads. That is where things break.

T-21: Is this specific to media and streaming, or is it a broader problem?

Sam Cooper: It is universal across data-intensive industries, but media operations have some unique characteristics that make the problem particularly acute. Content pipelines are time-sensitive — a live event has a hard deadline that does not move. The number of output formats and delivery specifications has exploded — a single piece of content might need to be transcoded into fifteen different profiles for different platforms and territories. And the volume has increased dramatically while team sizes have stayed flat or shrunk. When you combine time pressure, format complexity, and volume growth with manual handoff processes, the result is predictable: errors, bottlenecks, and teams that spend their time firefighting instead of improving their systems.

Automation before optimisation

T-21: You have a phrase you use with clients — “automate before you optimise.” What does that mean in practice?

Sam Cooper: It means that most organisations try to make individual steps faster when they should be eliminating steps entirely. I will give you a concrete example. A streaming platform we worked with had invested in an AI-powered quality assessment tool that could analyse transcoded output and flag artefacts in near real-time. Impressive technology. But the output of that tool was a report that was emailed to a QC team, who would manually review it, log the findings in a spreadsheet, and then send a re-transcode request through a ticketing system. The AI tool was doing its job in seconds. The human workflow around it was adding hours of latency.

As an AI workflow consultant, what we did was not replace the QC tool or build a better model. We automated the surrounding process — the quality assessment output now triggers conditional logic that either auto-approves clean assets, routes flagged assets directly into a re-transcode queue with the correct parameters, or escalates genuinely ambiguous cases to a human reviewer with all the relevant context pre-assembled. The AI model did not change. The workflow around it transformed the actual operational impact.

T-21: That sounds straightforward. Why do organisations struggle to do this on their own?

Sam Cooper: Two reasons. First, workflow automation sits in an organisational gap. The engineering team builds and maintains the tools. The operations team runs the processes. Nobody owns the connective tissue between them. When we come in, we are often the first people who have mapped the entire end-to-end process from ingest to delivery and asked the question: where does a human touch this, and does that touch add judgment or just add latency?

Second, there is a cultural bias towards building new capabilities rather than connecting existing ones. It is more exciting to pitch a board on an AI-powered content recommendation engine than to explain that you automated forty-seven manual steps in your content supply chain. But the forty-seven manual steps are costing you more money and causing more operational risk than the absence of a recommendation engine ever will.

The economics of workflow automation

T-21: How do you quantify the return on automation investment for clients?

Sam Cooper: We measure three things. First, time recovered — how many hours per week were spent on manual process steps that are now automated. This is the easiest to measure and the most immediately visible. Second, error reduction — how many re-transcodes, missed deliveries, or specification errors were caused by manual process failures. Every error in a content pipeline has a cost, whether that is a re-processing charge, a late delivery penalty, or a customer experience impact. Third, and this is the one that takes longer to materialise, throughput capacity — how much additional volume can the existing team handle without adding headcount. That third metric is where the long-term economics become compelling. If your operations team can handle thirty percent more content volume without hiring, the cost avoidance over two or three years dwarfs the automation investment.

T-21: Are there areas within streaming and broadcast operations where you see particularly high automation potential that organisations are not yet addressing?

Sam Cooper: Metadata management is the big one. The amount of manual metadata entry, validation, and correction happening across the industry is staggering. Every content asset needs technical metadata, descriptive metadata, rights metadata, localisation metadata, and platform-specific metadata. Much of this information already exists somewhere in the supply chain but is being manually re-entered or copy-pasted between systems. Automating metadata propagation and validation across the content lifecycle is probably the single highest-return automation project most media organisations could undertake today.

The other area is compliance and regulatory reporting. As content regulation becomes more complex across different territories, the reporting burden on operations teams is increasing. Automating the assembly of compliance documentation from existing system data is a significant opportunity that most organisations have not yet addressed systematically.

Advice for operations teams

T-21: For streaming or broadcast operations teams reading this who want to start their automation journey, where should they begin?

Sam Cooper: Map your processes before you buy any tools. Literally draw the flow of a content asset from the moment it arrives to the moment it reaches the end consumer. Mark every point where a human intervenes. Then ask yourself at each of those intervention points: is this person adding judgment, or are they acting as a manual integration layer between two systems? If the answer is the latter, that is your automation candidate.

Start with one workflow. Do not try to automate everything at once. Pick the process that fails most visibly or most frequently, automate it well, measure the impact, and use that evidence to build organisational confidence for the next project. Automation adoption in operations teams is as much a change management challenge as it is a technical one. Showing your team that automation makes their work better rather than replacing their jobs is essential for long-term success.

T-21: Sam, thank you for your time.

Sam Cooper: Thank you. The media and streaming industry is at an inflection point where the competitive advantage shifts from having the best individual tools to having the best-connected operational systems. The organisations that figure that out early will be significantly more efficient than their competitors within two or three years.

The post Why Streaming Operations Teams Are Automating Before They Optimise: A Conversation with Sam Cooper appeared first on T-21.

The post Why Streaming Operations Teams Are Automating Before They Optimise: A Conversation with Sam Cooper appeared first on T-21.

The distinction that matters is not whether AI valuations are inflated. Most informed observers accept that some correction is likely. The question that should concern broadcast engineers and media technology leaders is more specific: what happens to the production infrastructure that now depends on AI services if the companies providing those services restructure, reprice, or disappear?

Valuation Risk Is Not Technology Risk

It is worth separating two things that often get conflated. The underlying capabilities that machine learning brings to media workflows — automated transcription, intelligent metadata tagging, content-aware encoding, real-time language translation — are not going away. These are genuine technical advances that solve real operational problems.

What could change rapidly is the commercial landscape around them. The current AI market is characterised by enormous capital expenditure with limited near-term revenue to match. Cloud providers and AI platform companies are spending at a pace that assumes adoption curves will justify the investment within a few years. If those curves flatten or the returns take longer than projected, pricing models will change. Some providers will consolidate. Others will exit.

For a broadcaster running a 24/7 news operation where AI-powered transcription feeds downstream captioning, translation, and metadata workflows, a provider changing its API pricing by 300% or deprecating a model version is not an abstract financial event. It is an operational crisis.

The Dependency Problem

The more pressing concern is architectural. Over the past three years, media organisations have woven AI services into their workflows at an accelerating pace. MAM systems now rely on AI for automated tagging. Playout automation uses machine learning for content verification. Editorial tools depend on large language models for draft generation and summarisation.

In many cases, these integrations point directly at a single provider’s API. The workflow does not just use AI — it depends on a specific vendor’s implementation of AI. That is a fundamentally different risk profile.

The smart architectural response is abstraction. Organisations that have built orchestration layers between their workflows and the underlying AI models can swap providers without redesigning their entire production chain. Those that have hardcoded a specific provider’s SDK into their automation platform face a much harder migration path if circumstances change.

Microsoft’s Azure AI services, for example, now underpin a significant portion of enterprise media workflows through their integration with tools like Azure Media Services and the broader cognitive services suite. Google’s Vertex AI platform similarly powers an expanding range of media processing pipelines, from automated content moderation to real-time speech recognition. When organisations build directly against these platforms without an abstraction layer, they are making a bet not just on the technology but on the commercial stability and pricing trajectory of that specific provider.

Workforce Decisions Compound the Risk

There is a secondary risk that connects directly to the valuation question. Many media organisations have used the promise of AI-driven efficiency to justify workforce reductions. Headcount has been cut based on projected gains from tools that, in some cases, have been in production for less than a year.

If AI investment contracts and the efficiency gains do not materialise at the scale used to justify those reductions, these organisations face a compounded problem. They have fewer people to manage workflows that may suddenly require more human intervention, at exactly the moment when the automated systems they relied on become less reliable or more expensive.

This is not a hypothetical scenario. It is the predictable outcome of making permanent structural decisions based on technologies whose commercial trajectory is still uncertain.

What Broadcast Organisations Should Be Doing

None of this argues against using AI in broadcast workflows. The technology delivers genuine value in transcription, metadata generation, content analysis, quality monitoring, and dozens of other applications. Walking away from these capabilities would be operationally foolish.

But the way these capabilities are integrated matters enormously. Three principles should guide how broadcast organisations approach AI infrastructure in the current environment.

First, treat AI as a service layer, not a foundation. Workflows should be designed so that the AI component can be replaced without triggering a cascade of downstream failures. This means API abstraction, standardised data formats between pipeline stages, and explicit fallback procedures.

Second, maintain vendor optionality. Any workflow that depends on a single AI provider for a critical function should have a documented alternative path. This does not mean running parallel systems in production. It means having tested the migration path and knowing what it takes to execute it.

Third, preserve operational knowledge. The institutional understanding of how workflows function — including the manual processes that AI replaced — should not be allowed to disappear entirely. If automated transcription fails at scale during a breaking news event, someone needs to know how to manage the fallback. That knowledge evaporates quickly once the people who held it leave the organisation.

The AI capabilities now embedded in broadcast infrastructure are real and valuable. The commercial landscape supporting them is less certain than the technology itself. Building workflows that acknowledge both of those realities is not pessimism. It is engineering discipline.

The post Is Broadcast’s AI Infrastructure Built on Stable Ground? appeared first on T-21.

The post Is Broadcast’s AI Infrastructure Built on Stable Ground? appeared first on T-21.

Achieving sub-3-second glass-to-glass latency over standard HTTP delivery requires rethinking how content distribution networks handle file caching, request volume, and the relationship between origin servers and edge nodes. The protocols designed to make this possible, LL-HLS and LL-DASH, introduce architectural demands that break many of the assumptions CDNs were originally built around.

Why Traditional CDN Caching Falls Short

Conventional CDN architecture is optimised for large, complete files. A video segment gets encoded, written to disk, cached at the edge, and served to viewers. The model works well when segments are several seconds long and requests arrive at a predictable pace.

Low-latency streaming inverts this model. Instead of waiting for complete segments, LL-DASH delivers content through chunked transfer encoding — bytes are pushed to viewers as they are generated, before the segment file is fully written. LL-HLS takes a different approach, splitting segments into tiny “parts” that are served individually, with the manifest file itself blocking until the next part becomes available.

Both approaches dramatically increase the number of requests hitting CDN edge servers. A single viewer watching a standard HLS stream might generate one request every six seconds. That same viewer on LL-HLS can generate multiple manifest and part-file requests per second. Multiply that across thousands of concurrent viewers and the request volume becomes an infrastructure problem rather than just a bandwidth problem.

The Protocol Split: LL-DASH vs LL-HLS

The two dominant low-latency protocols take meaningfully different approaches to the same problem, and supporting both simultaneously within a single delivery pipeline is one of the harder engineering challenges in modern streaming infrastructure.

LL-DASH uses a single manifest and relies on timing-based chunk requests. The player begins downloading segments while they are still being generated on the origin server. Playback can start from any key-frame, which makes key-frame placement strategy a direct lever for controlling latency. More frequent key-frames mean lower latency, but at the cost of encoding efficiency and potentially higher bandwidth consumption.

LL-HLS, developed by Apple, takes a manifest-blocking approach. The server holds the playlist request open until the next part becomes available, then delivers an updated manifest pointing to the new content. Safari handles this natively, but third-party players like hls.js have had to implement their own handling of the blocking reload mechanism and byte-range requests that LL-HLS relies on to reduce request overhead.

The practical result is that a CDN serving both protocols simultaneously needs two different data transfer strategies running in parallel — accelerated downloading of small discrete files for LL-HLS, and continuous chunked delivery of incomplete files for LL-DASH.

What This Means for Edge Infrastructure

The shift to sub-3-second delivery has downstream effects on CDN edge architecture that go beyond simply handling more requests.

Connection duration changes fundamentally. In traditional CDN operation, a connection opens, delivers a cached file, and closes within milliseconds. With chunked transfer for LL-DASH, connections stay open for the duration of a segment — potentially several seconds — while bytes trickle through. This means edge servers carry higher concurrent connection counts and sustained CPU load even when aggregate bandwidth remains similar.

Caching logic needs to be rebuilt. Standard CDN caching mechanisms were not designed for files that do not yet exist in their final form. Serving a partially-written segment from cache while simultaneously appending new bytes from the origin requires purpose-built modules that standard web server configurations like Nginx’s proxy cache cannot handle out of the box.

Monitoring changes as well. When response time is measured in segment duration rather than file download speed, traditional performance dashboards become misleading. A 500ms response time on a LL-HLS manifest request is not a performance problem — it is the protocol working as designed, holding the connection until the next part is ready. Operations teams need monitoring that understands the difference.

Key-Frame Placement as a Latency Control

One of the less obvious but most impactful variables in low-latency streaming is key-frame frequency. In both LL-DASH and LL-HLS, playback can only begin from a key-frame. If key-frames are spaced two seconds apart, that sets a floor on achievable latency regardless of how fast the CDN delivers content.

Increasing key-frame frequency reduces latency but increases the bitrate required for the same visual quality, since key-frames are significantly larger than predicted frames. This creates a direct trade-off between latency and bandwidth efficiency that must be calibrated based on the specific use case — a sports betting application has different latency requirements than a concert livestream, and the key-frame strategy should reflect that.

Where This Is Heading

The industry consensus is moving toward sub-2-second HTTP delivery as the next target. Achieving this consistently at scale will likely require further innovation in edge processing, more aggressive use of RAM-based caching for micro-segments, and potentially new approaches to manifest generation that reduce the round-trip overhead inherent in the current request-response model.

For broadcast and streaming organisations evaluating their infrastructure roadmap, the immediate takeaway is that low-latency delivery is no longer an optional premium feature. It is becoming the baseline expectation for any live content where audience engagement depends on temporal proximity to the event — sports, news, gaming, interactive entertainment, and increasingly, enterprise applications like remote production and live commerce.

The CDN is no longer just a delivery layer. It is becoming an active participant in the streaming pipeline, and the architectural decisions made at the edge now directly determine the quality of experience at the glass.

The post How CDN Architecture Is Evolving to Deliver Sub-3-Second Live Streaming appeared first on T-21.

The post How CDN Architecture Is Evolving to Deliver Sub-3-Second Live Streaming appeared first on T-21.

Category: Streaming & Broadcast Technology Slug: /av1-codec-licensing-royalty-free-over

For the better part of five years, one of the strongest arguments for deploying AV1 was the claim that it was royalty-free. That claim was never entirely accurate, but in 2025 it became something closer to financially irresponsible to plan around.

The convergence of new patent pools, high-profile enforcement actions, and a fundamental shift in how codec intellectual property is monetised means that any streaming organisation deploying advanced codecs — whether AV1, HEVC, or VVC — now faces a licensing landscape that demands attention from legal and finance teams, not just engineering.

What Changed in 2025

Three developments reshaped the codec licensing environment in ways that affect every publisher operating above a certain scale.

First, Access Advance launched its Video Distribution Patent (VDP) Pool in January 2025, covering content distribution using HEVC, VVC, AV1, and VP9. This was not a device-side licensing programme — it targets the act of encoding and delivering content itself. Royalty rates, published in July 2025, are calculated based on whichever is highest among three metrics: average monthly active video users, average monthly video subscribers, or semi-annual streaming revenue.

Second, Sisvel announced that its AV1 patent pool had licensed roughly 50% of the finished-product AV1 hardware device market — covering TVs, set-top boxes, and other consumer hardware. For a codec launched under the banner of royalty-free, having half the device market paying licensing fees fundamentally undermines that positioning.

Third, Nokia and Amazon settled a global patent dispute that included content-side royalties for H.264 and H.265 usage across Prime Video, Freevee, and Twitch. This was one of the first confirmed settlements where a tier-1 streaming service paid for the act of distributing codec-encoded content, not just for the hardware decoding it. The message to the industry was unmistakable: if Amazon can be compelled to settle, no major service is immune.

The New Licensing Landscape at a Glance

Understanding who is charging what, and for which codecs, requires tracking multiple overlapping programmes. The table below summarises the current state of the major content-side and device-side licensing pools:

Programme	Codecs Covered	Licensing Type	Notable Detail
Access Advance VDP Pool	HEVC, VVC, AV1, VP9	Content distribution	Annual cap + de minimis waiver for small services
Avanci Video Pool	HEVC, AV1	Content distribution	No cap or de minimis exception announced
Sisvel AV1 Pool	AV1	Device licensing	~50% of AV1 hardware market licensed
Access Advance / VCL Advance	HEVC, VVC	Device licensing	Consolidated from Via LA acquisition
Individual patent holders	H.264, HEVC, AV1, streaming	Direct enforcement	Nokia, InterDigital, Broadcom actively pursuing claims

What makes this landscape particularly complex is the overlap between programmes. Sixteen licensors are common to both Access Advance’s VDP Pool and Avanci’s Video Pool, which means licensees paying into both receive an offset for double royalties — but the exact offset is not publicly disclosed, making cost modelling difficult without direct engagement.

The Break-Even Math Has Changed

Before content-side licensing became enforceable, the economic case for deploying AV1 or HEVC beyond H.264 was relatively straightforward: spend more on encoding compute to save on CDN bandwidth. A 30% bitrate reduction over H.264 translated directly into CDN cost savings, with the only incremental cost being encoder complexity.

That equation has fundamentally shifted. For services above the VDP Pool thresholds, the calculation now includes encoding compute, potential content-side royalties that can reach into eight figures annually for the largest services, and the possibility of direct patent enforcement from individual holders.

Meanwhile, CDN costs have declined significantly since 2019 when these efficiency arguments were first being made. The bandwidth savings from deploying AV1 over H.264 are real, but the dollar value of those savings per gigabyte delivered is substantially lower than it was five years ago.

For services delivering HDR and 4K premium content, the codec choice remains operationally necessary — AV1 and HEVC provide capabilities that H.264 simply cannot match at those quality tiers. The royalty costs become a necessary cost of doing business. But for FAST services, ad-supported platforms, and others working primarily with 8-bit 1080p content, the efficiency argument that justified advanced codec deployment now requires a much more careful financial analysis.

Where AV1 Stands Despite the Licensing Questions

None of this means AV1 adoption is slowing. The opposite is true.

Netflix recently reported that AV1 powers roughly 30% of its streams and has expanded into HDR delivery, achieving feature parity with HEVC. On the device side, Netflix noted that 88% of large-screen devices submitted for certification between 2021 and 2025 supported AV1, with the vast majority offering full 4K at 60fps capability.

Browser support has been near-universal since AV1’s early days. Mobile remains the one platform where hardware decode lags significantly behind HEVC, though the Alliance for Open Media’s investment in the dav1d software decoder has enabled efficient AV1 playback on Android devices without dedicated hardware.

The codec itself has reached critical mass. The question is no longer whether AV1 works or whether devices support it. The question is what it costs to use it, and whether the organisations deploying it have adequately accounted for that cost.

What Comes Next: AV2 and the IP Question

The Alliance for Open Media finalised the AV2 specification in late 2025. Early testing shows compression efficiency gains in the high-20% to mid-30% range over AV1, potentially closing much of the gap with VVC.

But the more consequential signal came from InterDigital’s acquisition of AI-native compression startup Deep Render in October 2025. InterDigital — a non-practicing entity with an $8 billion market cap built on licensing codec and wireless IP — explicitly framed the acquisition as positioning for “the next generations of video technologies.” If AI-native compression techniques are being accumulated by the same organisations that monetised H.264, HEVC, and VVC, the post-AV2 generation is unlikely to reset the royalty conversation.

For publishers planning their codec roadmaps, the implication is clear: the era of assuming any advanced codec is royalty-free is over. The practical question has shifted from “can we avoid paying for codecs?” to “which codecs are worth paying for, at what scale, and with what financial provisions in place?”

That is a healthier question. It just requires different people in the room when it is being answered.

The post The Codec Licensing Shift: Why AV1’s “Royalty-Free” Era Is Effectively Over appeared first on T-21.

The post The Codec Licensing Shift: Why AV1’s “Royalty-Free” Era Is Effectively Over appeared first on T-21.