Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
The thing about codec adoption is that years of hard work and development must occur before a single stream gets distributed by an independent publisher. The bottleneck is almost always the decode side, accumulating sufficient compatible players to make the new codec economically viable. One study, titled Spotlight on HEVC: The codec of choice for the video streaming industry, sponsored by InterDigital, posited that until 30% of a service’s installed base played a new codec, deploying it in addition to existing codecs wasn’t economically viable.
It can take years for a new codec to cross that threshold. If you’re measuring codec progress solely through the lens of actual publisher deployments, you miss a lot of the foundational activity that makes that happen.
In this regard, a recent LinkedIn post by my erudite colleague Robert J.L. Moore catalogued several announcements that indicate progress towards that goal by the VVC codec, particularly in the mobile space. This article will identify these announcements, discuss their significance, and their short and long term impact.
Contents
MediaTek Announces Mobile SoC with VVC Decode
First up is the launch of MediaTek’s Dimensity 9600 Pro, which is one of the first mobile chipsets to add hardware support for H.266/VVC video decode (Figure 1). That decode distinction matters, because it means playback acceleration only. As shown in Figure 1, the onboard camera will either use HEVC or H.264 for recording.
The first phones using the chip are already scheduled: vivo has confirmed that the X500 Pro and X500 Pro Max will launch in China on September 21, while OPPO has confirmed that the Find X10 Pro Max will launch in China on September 22.
It’s not surprising that both early deployments are in China, which has been much friendlier to VVC than other markets. While these do start the clock running towards that 30% in China, getting to 30% will likely take at least 2-3 years, depending upon if and when hardware VVC decode appears in mid-range and budget phones.
Of course, VVC hardware decoding deployments in China have little impact on publishers not serving that market. Publishers in other markets will have to wait for smartphones with VVC hardware, or plan on relying upon VVC software decode, which is discussed below.
VVC in Android 17
This is an “in-case-you-missed-it” section, since it occurred back in February 2026, when Google added VVC encoding and decoding to the Android 17 media framework. This establishes a standardized interface between VVC decoder developers and streaming services, eliminating the need for proprietary integrations across both mobile and Android TV.
Android 17 supplies the framework APIs and MP4 parsing support, but not a bundled VVC decoder. SoC vendors and OEMs can enable playback by registering either a hardware or software VVC decoder with Android’s media subsystem. Once registered, apps and streaming services can discover VVC capability through standard Android mechanisms and initiate playback.
In other words, Android 17 does not make VVC universal across Android devices. It creates the common plumbing that lets hardware decoders, and software decoders like the one Ittiam is developing, plug in when vendors choose to support them.
As Moore insightfully pointed out in his LinkedIn post, “Google worked on #AV1, not VVC, and given its druthers, would probably rather have its users use AV1. That Google made any gesture that could help VVC adoption in Android indicated that its partners in that ecosystem – MediaTek, Qualcomm, and/or Samsung – had shared plans with Google to include VVC in their near term product roadmaps.”
Before you get teary eyed about Google’s largess, note that it added HEVC support to Android in 2014, roughly 23 months after HEVC finalized. That’s because HEVC took off much more quickly than VVC due to the 4K/HDR boom. In contrast, VVC was finalized in 2020, and it took around 5.5 years for Google to support it in Android. This proves Moore’s point; Google was responding to pressure from ecosystem partners, not encouraging developers to support a feature that might diminish the appeal of AV1 or the upcoming AV2.
MC-IF and Ittiam Announce Open-Source VVC Decoder
The next important announcement came from the Media Coding Industry Forum, which introduced an open-source VVC software-decoder initiative with Ittiam at IBC. Some perspective.
As discussed above, it takes two to three years for phones with hardware-based VVC decode to achieve 30% of the market. It’s also likely that only premium phones will have VVC (or AV1/AV2) hardware decode due to cost constraints. This means that there will likely always be a large market of lower cost devices without AV1, AV2, or VVC decoding.
The workaround for this is software decoding. The Alliance for Open Media (AOM) recognized this and funded a highly optimized software player called Dav1d. In mid-2025, I compared Dav1d’s playback performance with the only open-source VVC player available, from Fraunhofer, which the company describes as ” a minimal proof-of-concept VVC player for the web using Web Assembly.” The Fraunhofer player isn’t nearly as optimized as the multi-generation dav1d player and performed accordingly, as you see in Table 1.
On premium devices, all without AV1 or VVC hardware decoding support, performance was fine for both codecs. But on sub-$100 devices, Dav1d outshone Fraunhofer’s player.
I’m not saying that AV1 decoding is more efficient than VVC. There’s evidence that several of the larger Chinese streamers/VVC patent owners like Tencent and Youku have created their own highly optimized players, but only for deployment within their own ecosystems. But smaller streaming publishers can’t develop their own optimized players, and don’t have to for AV1. For this reason, the lack of an optimized open-source decoder posed a significant competitive disadvantage vs. AV1 and Dav1d.
The Ittiam Open-Source Player
An obvious strategic move was to create a competitive open-source VVC decoder, and that is what the MC-IF and Ittiam initiative is designed to do. According to the press release, MC-IF and Ittiam plan to release an open-source VVC decoder optimized initially for Android arm64. The announced roadmap includes a C/C++ interface, FFmpeg integration, and Android JNI access, which should make the decoder usable by Android developers and in tools and workflows built around FFmpeg.These same features make later portability plausible, but MC-IF has not announced plans to support Linux, Windows, macOS, iOS, browsers, or other platforms.
If it performs well, the decoder could give VVC much of what dav1d gave AV1: a freely available, high-performance software playback option that publishers and developers can use without developing or licensing their own player. That’s particularly important during the next several years, while hardware VVC decode works its way into the phone installed base.
Assuming a normal open-source license, users shouldn’t owe MC-IF or Ittiam a software-license royalty. That doesn’t change the patent situation. A publisher, device maker, or software distributor may still have to pay VVC patent royalties to a pool or individual patent owner. But open-source decoder code would significantly streamline early testing and deployments.
Ittiam isn’t starting from scratch. It published an optimized VVC mobile-decoder paper in 2020, so it has prior experience tuning VVC decode for mobile platforms. At IBC, MC-IF showed an early version of the decoder running live on Android devices. The demo used an ARM NEON-optimized VVC decoder and targeted real-time playback of both 8-bit and 10-bit video, with power and memory consumption low enough for sustained HD playback on mobile hardware.
MC-IF says the implementation targets up to 150% faster decoding than existing software-decoder baselines, but didn’t identify the baselines, the Android devices used, or the resolution, frame rate, content, power, or memory test conditions. As with all products, performance won’t be known until a final version is available for testing.
We also don’t know about availability. MC-IF hasn’t announced a public repository or release date, and the release says the collaboration is subject to final agreements between the parties. These caveats and unknowns aside, the open-source player is undoubtedly a long overdue development that should go a long way to promote VVC testing and potentially deployment.
Multilayer VVC
Moore also mentioned that InterDigital, Inc. and NHK demoed a MultilayerVVC profile at #IBC. I wasn’t familiar with Multilayer VVC, so this one required a deep look. Here’s what I learned.
VVC Multilayer coding will sound familiar to anyone who remembers H.264’s Scalable Video Coding (SVC) or has worked with Low Complexity Enhanced Video Coding (LCEVC). Like both technologies, VVC Multilayer uses a base layer plus one or more enhancement layers to deliver different quality levels to different viewers (Figure 5). The base layer delivers a complete version of the program at some lower quality or feature level. Enhancement layers add additional content, whether that’s resolution (Figure 5), picture quality (Figure 5), a sign-language presentation (Figure 6), alternate framing, or an ad overlay (Figure 7).
Beyond the content overlay, InterDigital claims that VVC Multilayer enhances spatial/quality scalability, though specific performance details are not shared. A MainConcept product description states that VVC Multilayer delivers “Spatial Scalability through inter-layer prediction, which reuses data from lower layers to reduce redundancy and improve overall compression efficiency.”
To explain, assume that a normal encoding ladder had an HD rung at 6 Mbps, and a UHD rung at 12 Mbps. Using VVC Multilayer, the HD layer would still be 6 Mbps, but the UHD layer might be 5 Mbps, as shown in Figure 5. Neither MainConcept or InterDigital quantified this efficiency, so these numbers are mine.
Deploying VVC Multilayer
The strongest use case for VVC Multilayer is broadcast, satellite, cable, managed-IPTV multicast, and other one-to-many networks. As shown in Figure 5, a broadcaster that transmits separate HD and UHD versions of the same channel sends both to every receiver. In the case of a normal encoding ladder, if the HD version was 6 Mbps, and the UHD version 12 Mbps, the bandwidth total would be 18 Mbps.
With VVC Multilayer, the broadcaster transmits an HD base layer at 6 Mbps, plus a 5 Mbps UHD enhancement layer for a total of 11 Mbps. HD receivers use the base; UHD receivers combine the layers.
Those of us who cut the cord years ago may underestimate the scale of the opportunity: broadcast and cable still accounted for 38.2% of total U.S. TV viewing in July 2026. For one-to-many networks that need to carry HD and UHD service tiers simultaneously, a layered approach could preserve the same service model while using less transmission capacity. In our example, the 11 Mbps layered stream uses about 39% less capacity than the 18 Mbps pair of independently delivered versions. With VVC Multilayer, this capacity could support more channels, higher-quality services, or other uses of scarce spectrum.
VVC MultiLayer in Unicast Streaming
For unicast streaming, VVC Multicast still delivers storage-related savings, but the bandwidth savings are limited to the undefined spatial scalability discussed above.
The more interesting streaming use cases may be overlays, personalization, accessibility, localization, and alternate framing. In those cases, the service can distribute the common program once and send only a relatively small additional layer to viewers who select a sign-language feed, localized graphic treatment, branded overlay, or reframed presentation (Figure 6).
Figure 7 shows how VVC Multilayer delivery can enable localized, L-shaped advertising around a shared live sports broadcast. A base layer carries the same live match to every viewer. Optional enhancement layers add a small L-shaped graphic around the bottom and right edges of the video for specific markets, for example, a New York-branded overlay for viewers in New York and a different Los Angeles-branded overlay for viewers in Los Angeles. Because the central match picture remains in the base layer, the local advertising can be added without creating or distributing a separate full program feed for each city.
Viewers with a base-only receiver see the unmodified match, while compatible viewers decode the same VVC Multilayer stream together with the local advertising enhancement layer.
To summarize, VVC Multilayer’s clearest near-term fit is a closed-loop, one-to-many deployment such as managed IPTV multicast, cable, satellite, or terrestrial broadcast. In those systems, an operator controls the receivers, encoder, network, and service profile, and can transmit the common base and enhancement layers once to many viewers. That is where a layered HD/UHD service can turn an encoding efficiency into a meaningful aggregate transport-capacity saving.
On the public internet, the feature still works, but the case is less straightforward. Device, browser, app, DRM, packaging, and decoder support must be deployed across a much less controlled ecosystem. The InterDigital/NHK demonstration used a Multilayer software decoder, showing that software playback is possible. But player capabilities and performance will vary, and streaming publishers are unlikely to invest in an advanced VVC Multilayer presentation until a meaningful share of their target audience can reliably experience it.
Tencent VVC Case Study
While the InterDigital/NHK demo was impressive, there is no stronger technical confirmation than a production deployment. Unlike AV1, whose supporters like Netflix, Meta, and YouTube have extensively publicized their deployments and performance results, the VVC user community has been comparatively quiet.
That is why Tencent Cloud’s May 2026 post, “Innovations of H.266 in Live Streaming,” is notable. Tencent says its proprietary real-time VVC encoder is deployed on WeChat Channels and WeTV, supports more than 10 Tbps of concurrent bandwidth, and has helped customers save hundreds of millions in bandwidth costs while improving startup time and stutter rates.
Tencent also reports streaming premium 1080p delivery at approximately 1.3 Mbps, compared with 5.1 Mbps for AVC in its benchmark. These are Tencent’s own claims, not independently audited results, but they provide a concrete account of VVC operating in a large-scale commercial live-streaming environment.
In the past, codec competitions were framed as a technical contest, fought over BD-Rate results and features such as HDR, scalability, and Multilayercoding. AV1 and the Alliance for Open Media changed the dynamic. The battle became at least partly about marketing, with deployment announcements from a handful of prominent members creating the perception that AV1 had become the dominant codec. Early claims that AV1 was royalty-free reinforced the impression that it had achieved broader publisher adoption than the public record necessarily supports.
For whatever reason, the VVC user and patent-owner community largely declined to play that game, at least when it came to documenting successful real-world deployments. In a codec market increasingly shaped by visibility and narrative, Tencent’s case study may be more persuasive than a dozen broad press releases proclaiming how far VVC has progressed. It identifies named services, describes the deployment, provides scale and performance claims, and explains the technical measures Tencent says made real-time VVC possible.
The only way to compete in a marketing war is to recognize that it is a marketing war. Between the Ittiam open source player and this Tencent case study, it appears that the nickel has finally dropped within the VVC patent-owner community.
To Be Complete
Moore also states that “And, as I’ve noted in prior posts, companies like Meta have recently taken pool licenses for VVC.” True, Meta joined the Access Advance VDP Pool, which includes HEVC, AV1, VP9, and VVC. But as I wrote in this LinkedIn post, Meta deploys VP9 and AV1 at scale, with very little use of HEVC and no publicly evidenced intent to use VVC.
Within the VDPP, Meta could use VVC without additional royalties. But, as the recent Guidelines from Munich remind us, that would open Meta to substantial additional claims from individual VVC patent owners that, as a deep-pocketed streamer, Meta could certainly expect. To me, Meta joining the VDPP pool is a great indicator that 1) resistance to royalties on streaming is futile and 2) AV1 and VP9 are not royalty free. Taking it as an endorsement of VVC is a step too far.
What it all Means
Together, the first three announcements go a long way towards getting Android devices to that 30% target. Hardware will take awhile, and we don’t know how efficient the software player will be, but it’s a start.
Why no iOS? Because that stack and hardware is completely controlled by Apple, and Apple does what Apple does when Apple wants. Apple is a substantial owner of VVC patents, though how and when it impacts its decision to implement VVC remains to be seen.
Figure 8. Making the Android platform more accessible to VVC playback.
VVC Multilayer is an interesting feature, though it appears better suited to broadcast and other one-to-many delivery models than to unicast streaming. The spatial-scalability benefit most relevant to unicast streaming remains unmeasured in publicly available results.
Taken as a whole, these announcements present encouraging evidence that the VVC community is investing both development and marketing dollars to meaningfully promote VVC. The first visible sign of progress will be favorable reviews of the open-source player. If that’s competitive against the AV1 Dav1d player, it will significantly boost VVC’s mindshare and potential for mobile-centric publishers.
