VLC 3.0.22 RC1 Vetinari Adds Native Windows ARM64 Build and Stability

VLC’s long drought of user-visible updates has ended with a pragmatic, compatibility-focused release candidate: VLC 3.0.22 RC1 (Vetinari) — and for Windows on Arm users the headline is clear: VLC now ships native ARM64 builds for modern Windows machines, alongside a bundle of decoders, demuxers, UI updates, and security hardening intended to steady the 3.0.x branch while VLC 4.0 continues development.

Background / Overview​

VLC 3.0, codenamed Vetinari, has been under active maintenance while the project simultaneously advances work on the next-generation VLC 4.0. The 3.0.22 RC1 release is a conservative, maintenance-first update: it does not reinvent the player but plugs long-standing playback bugs, tightens security, modernizes some build paths, and — crucially for many Windows users — provides an official Windows ARM64 build. That combination makes this RC both technically important and strategically symbolic for Windows on Arm adoption.
This article breaks down what changed, why it matters for Windows on Arm and wider VLC users, and what risks or limitations remain before you replace your daily VLC install with the RC.

---

Why the ARM64 build matters​

Native application builds for Arm64 hardware matter for three practical reasons: performance, battery life, and compatibility with hardware codecs and acceleration paths.

• Emulation overhead is eliminated when the binary runs natively on Arm silicon, which typically translates to lower CPU utilization for the same workload.
• Hardware-accelerated decode paths are easier to leverage and more predictable from a native binary, improving thermal behavior and battery life on fanless laptops and tablets.
• Native builds mean less reliance on Microsoft’s emulation layers, which can obscure bugs and driver differences.

VLC’s ARM64 build explicitly targets modern Windows Arm platforms (Windows 10 RS5/1809 minimum cited in packaging notes), and the change is documented in multiple distro and press write-ups covering the RC.

What Windows-on-Arm users should expect​

• Lower CPU usage for heavy formats (AV1, high-bitrate H.265, large ProRes files) when the native code path avoids emulation.
• Better compatibility with platform-specific hardware acceleration (where drivers/GPUs expose decode to the system).
• Fewer weird, emulation-triggered stability issues — but not guaranteed parity with x64 in every corner because driver support varies by OEM and GPU vendor.

Practical caveat: hardware-accelerated features still depend on GPU drivers and vendor stacks. Native VLC reduces one layer of variability but does not remove the need for current drivers or OS support. Test before migrating critical workflows.

---

What’s actually in 3.0.22 RC1 — feature and fix rundown​

The RC’s changelog is focused and detailed. Highlights include:

• Native Windows ARM64 builds — official Arm64 binaries intended for Windows 11 on Arm and compatible Windows 10 Arm releases.
• Qt UI improvements — a new “use a dark palette” option for the Qt-based desktop UI and compilation support for Qt6 while retaining support for modern Qt5.
• Playback fixes and codec work — improvements for AV1 (dav1d options), ProRes, Opus channel mapping, FLAC seeking and picture handling, and fixes across multiple demuxers.
• Security hardening — a notable set of fixes discovered by fuzzing programs (including reports tied to oss-fuzz) and supported via security funding; the release claims a large volume of security fixes compared with prior minor releases. This deserves cautious interpretation until official VideoLAN advisories are posted.
• Legacy decoder defaults changed — decoding via libdca, libmpeg2, and liba52 is disabled by default, favoring libavcodec for most users. This reduces maintenance surface and aligns with a single robust decoding pipeline.
• Windows XP SP3 compatibility adjustments — limited restoration of XP SP3 support with restrictions (SystemParametersInfo calls restricted to XP), reflecting the project’s continued willingness to accommodate legacy use cases in a safer way.
• Quality-of-life change — on Windows, VLC now permits renaming, moving, and deleting the file currently being played, a practical workflow improvement for users who manage large media libraries.

A condensed changelog of the RC has been circulated in community posts and packaging trees; distro maintainers and several independent outlets reproduced the core patch list while the RC tag circulated in the VLC git tree.

---

Technical analysis: what moved under the hood​

Decoder consolidation and default behavior​

Disabling libdca, libmpeg2, and liba52 by default in favor of libavcodec is a maintenance and reliability move. Libavcodec benefits from active maintenance and wide testing across platforms; making it the default decoder reduces fragmentation and likely reduces crash surface. However, in rare edge cases or for legacy content, packagers or advanced users may need to re-enable older libraries or build with optional flags. Expect some distro-specific packaging to expose build-time options for compatibility.

AV1 and dav1d options​

The changelog adds a dav1d-all-layers option and other AV1-related adjustments. For multi-layer AV1 content and certain hardware/software stacks, having dav1d control flags helps tune performance and correctness. That’s a targeted improvement for modern compression formats where implementations and corner cases still appear in the wild.

Qt6 build support and dark palette​

Moving the build system to support Qt6 is a forward-looking step that prepares VLC’s desktop front end for future evolution. The dark palette option is important for parity with modern OS-wide dark themes and complements accessibility and power-savings workflows. Expect incremental visual polish as maintainers continue to refine the Qt6 experience.

AMD GPU Frame Rate Doubler (Direct3D11)​

The RC adds an experimental AMD-specific frame interpolation feature via Direct3D11 (referred to in some reports as a frame-rate doubler or AI interpolation). This is an experimental media enhancement that will be polarizing — useful to some users for smoother motion, objectionable to others for soap-opera effect. The feature’s activation and driver dependencies will constrain where it’s useful. Multiple outlets mention the addition; testers should evaluate the feature on current AMD drivers.

---

Security: lots of fixes, but interpret carefully​

The 3.0.22 RC1 emphasizes a large number of security fixes, with a portion attributed to fuzzing programs like oss-fuzz and supported by security grants. Independent press noted the project called out a large security haul for this RC, and packagers referenced crash hardening fixes across demuxers and decoders. That is good news for users — especially those running VLC against untrusted media — but security claims should be parsed:

• “Most security fixes ever” is a broad claim and is currently best treated as an indicator of significant hardening rather than an exact metric. The official VideoLAN advisory pages and the project’s NEWS file should be consulted for CVE-level details and for guidance on severity and CVE assignments. Until VideoLAN publishes the official security advisory for 3.0.22, treat the quantitative security claim with caution.

Practically: the RC already addresses multiple crash and memory-handling issues; users who routinely open untrusted or internet-sourced media will benefit from these fixes once the stable release is out.

---

Windows XP SP3 and legacy support — pragmatic but odd​

Restoring compatibility with Windows XP SP3 (with restrictions) is notable because most major projects have long since stopped formal support for XP. VLC’s choice reflects a userbase that still contains hobbyists and embedded scenarios that need legacy support. The project constrained certain Windows API calls (SystemParametersInfo) to XP to avoid regressions elsewhere, a reasonable compromise.
Security-minded readers should be aware: running modern software on ancient OSes remains risky, because OS-level protections and vendor support are absent. The fix is about compatibility, not an endorsement of using XP as a secure platform.

---

Testing and upgrade guidance for Windows on Arm users​

If you run Windows on Arm and want to try the RC, follow a cautious test plan:

• Back up your VLC configuration folder (AppData and preferences).
• Install the ARM64 RC in a separate directory or virtual machine; do not overwrite a stable production install.
• Test representative files: AV1/Opus MKVs, high-bitrate HEVC, ProRes multitrack files, and subtitle formats you rely on.
• Check the codec/hardware acceleration path in Tools → Messages to confirm whether hardware decode is used and which backend is active.
• Measure CPU usage and battery/thermal behavior during extended playback sessions.
• If you depend on specific plugins or integrations (e.g., network shares, UPnP, SFTP), validate them thoroughly, as demuxer fixes sometimes interact with network stacks.
• If you see regressions, collect verbose logs and file a reproducible bug report to the VLC bug tracker.

Community-sourced test plans and guidance have already circulated in forums and packaging threads; they’re worth consulting before upgrading on a production machine.

---

Risks, limitations, and what remains unresolved​

• RC status: a release candidate is not a final stable release. Regression risk remains; do not deploy RC builds to mission-critical systems without testing.
• Driver variance: hardware acceleration behavior and the new AMD frame interpolation depend heavily on vendor drivers and OS support. Expect different outcomes across OEMs and generations.
• Feature polarities: user-visible enhancements like AI-based frame interpolation have subjective acceptance and might produce artifacts; rollout is experimental.
• Legacy toggles: disabling old decoders by default may cause corner-case playback regressions for niche files; advanced users and packagers may need to re-enable legacy libraries where necessary.
• Security transparency: while a large number of security fixes are claimed, official CVE mapping and severity classification should be awaited from VideoLAN. Until then, the security impact remains qualitatively positive but quantitatively tentative.

---

What this tells us about VLC’s strategy​

VLC’s 3.0.22 RC1 demonstrates a conservative strategy: backport useful modernizations (Qt6 build paths, ARM64 binaries) while focusing primarily on reliability, decoder consolidation, and security. This is a practical approach for a project that must support a vast range of architectures, formats, and user expectations.
Two strategic signals stand out:

• The official ARM64 builds indicate VideoLAN recognizes Windows on Arm as a sustained platform and wants to reduce friction for mainstream adoption. That matters more now that OEMs ship more Arm devices and Microsoft’s emulation story is evolving.
• The push to favor libavcodec by default and to support Qt6 signals a maintenance-first evolution: less fragmentation, fewer custom decoders in active use, and a cleaner path forward for GUI modernization.

---

Bottom line recommendations​

• Windows on Arm users: this RC is the most promising path so far to get native VLC performance on Arm devices. Test carefully and evaluate hardware-accelerated decode paths before switching your main install.
• Power users relying on edge-case decoders: be ready to re-enable legacy libraries if you depend on specific behaviors from libdca/libmpeg2/liba52; however, prefer libavcodec where possible for reliability.
• Security-conscious users: the RC appears to address numerous vulnerabilities and crashes, but wait for the formal VideoLAN advisory and stable release for full CVE mapping and severity notes.
• Packagers and distro maintainers: verify build flags around Qt6 support, ARM64 packaging specifics, and legacy decoder options; this RC will require coordinated packaging changes across distributions.

---

Final thoughts​

VLC 3.0.22 RC1 isn’t a flashy reimagining of the player — it’s a careful, necessary maintenance release that modernizes compatibility where it counts: a native Windows ARM64 build, Qt6 readiness, notable decoder fixes, and a long tail of stability and security improvements. For Windows on Arm users, the arrival of an official ARM64 binary removes a major friction point and signals that mainstream open-source tooling is catching up with Microsoft’s Arm push. For the broader VLC audience, the release shows the maintainers defending reliability and security while preparing the codebase for a gentler evolution toward VLC 4.0.
For now, let testers drive the RC and file clear bug reports; once the stable release and full advisories are published, the broader userbase should see immediate practical benefits — particularly on Arm devices — without sacrificing the reliability that made VLC ubiquitous in the first place.

---

Source: Windows Report Using Windows 11 on Arm? The Latest VLC Update Finally Supports It