Navigation section

VLC 3.0.22 RC1: Windows ARM64 native build, XP support, dark UI

  • Thread Author
VLC’s long-running 3.0 branch has taken a significant step forward with the appearance of a release candidate for version 3.0.22, and the changes matter for two very different groups of users: the growing population of Windows 11 on Arm owners, and a tiny but vocal set of hobbyists still running Windows XP. The release candidate (tagged in mid-September) brings an official Windows ARM64 build, a native dark palette option, compilation support for modern Qt versions, AMD GPU frame-rate doubling via Direct3D11, and a long list of decoder, demuxer, and demux-level fixes — alongside what several outlets characterize as a very large set of security fixes. This isn’t a revolutionary new VLC, but it is a consequential, pragmatic release that modernizes compatibility while tidying up long-standing playback issues.

Open laptop on a desk displaying a dark software UI with a green square logo, illuminated by blue light.Background / Overview​

VLC 3.0, codenamed “Vetinari,” has been maintained actively despite the project’s parallel work on VLC 4.0. The 3.0.22 release candidate — referred to in community and press reports as 3.0.22 RC1 — is the first formal step toward a stable 3.0.22. The RC includes a mix of platform updates, feature improvements, and many bug and security fixes accumulated since the previous stable release in 2024.
Two of the most visible and talked-about changes are:
  • Native Windows ARM64 builds (official support for Windows on Arm).
  • Reinstated compatibility with Windows XP SP3 (with restrictions in how SystemParametersInfo is called).
Beyond those headline items, the changelog (as reflected in community summaries and the project’s source tree) lists a number of codec, container, subtitle, and demuxer fixes — plus UI build updates (Qt6 support), a dark UI option for the Qt interface, and an experimental AMD frame-rate doubling feature.

What’s in 3.0.22 RC1 — Quick Changelog Summary​

The release candidate’s changes are focused, practical, and primarily conservative maintenance work rather than new, radical features. Key points include:
  • Official Windows ARM64 builds — native Arm64 executables intended for Windows 11 on Arm and recent Windows 10 arm64 systems.
  • Add option to use dark palette (Qt) — a native dark-mode theme option for the Qt-based VLC UI.
  • Compilation support for Qt6 (and newer Qt5) — modernizing the UI build path.
  • Fix support for Windows XP SP3 — restores compatibility for legacy XP SP3 installs while limiting some API calls for safety.
  • Allow renaming/moving/deleting of the playing file on Windows — removes a prior lock that prevented file operations on files opened by VLC.
  • Fixes to a wide set of decoders and demuxers — Opus mapping, ProRes, XVID hardware decoding on macOS, AV1/dav1d flags, FLAC pictures/seeking fixes, and more.
  • Disable certain legacy decoders by default — libdca, libmpeg2, liba52 are disabled by default in favor of libavcodec.
  • Fixes and crash hardening reported by fuzzing programs and external reporters — multiple demux/decoder crash fixes.
  • Add AMD GPU Frame Rate Doubler (Direct3D11) — experimental frame interpolation on AMD GPUs (via Direct3D11 path).
  • Several bug fixes for DVD, UPnP, SFTP seeking, JPEG/ASF edge cases, and UWP device queries.
This is a condensed list; the full RC changelog contains many smaller, technical changes targeted at edge-case playback and security hardening.

Why Windows ARM64 support matters now​

The inclusion of an official Windows ARM64 build for VLC is the most consequential compatibility announcement for modern Windows users. The broader context:
  • Windows on Arm has moved from niche to mainstream for several OEM platforms (Copilot+ and Snapdragon X devices). Vendors and Microsoft have invested heavily in the ecosystem.
  • Developers have increasingly released native Arm64 builds of mainstream apps to deliver better performance and battery life than emulated x64/x86 code.
  • For media apps specifically, native ARM codecs and hardware-accelerated paths reduce CPU load, temperature, and battery drain — important on thin, fanless Arm laptops and tablets.
What this means for VLC users on Arm devices:
  • Native execution avoids emulation overhead and improves efficiency, particularly for high-resolution or high-bitrate content.
  • Hardware-accelerated decoders (when available and configured) can offload video decoding to integrated GPUs, saving CPU cycles and improving playback smoothness.
  • Native builds are typically a boon for long-form playback and background tasks (e.g., media servers or heavy transcoding).
However, a few practical caveats apply: the RC is a testing snapshot and not a general distribution release, and community reports from earlier 3.x nightlies show some instability in Arm-specific builds. In short: native VLC on Arm is now an official priority — but early adopters should test carefully.

The Windows XP fix: nostalgia, edge cases, and risk​

It’s unusual — almost whimsical — to see a modern VLC release explicitly fix support for Windows XP SP3. That change is a small but deliberate nod to the handful of users who still run legacy systems for retro projects, embedded uses, or network appliances.
Important considerations:
  • The change is limited: certain API calls (SystemParametersInfo) are restricted, likely to avoid abusing deprecated Windows behavior and to improve stability and security on XP.
  • Windows XP is long out of support and poses significant security risks if exposed to networks or untrusted content. The backward compatibility fix helps specific isolated use cases (e.g., offline kiosks), but it shouldn’t be taken as a recommendation to run XP on the open internet.
  • From a software maintenance perspective, restoring XP compatibility is low-effort for a maintainers’ community that still wants to keep the codebase inclusive — but the continuing presence of XP-support paths increases surface area for legacy regressions and subtle compatibility bugs.
This change is mostly cosmetic for the majority of users, but it reminds readers that VLC continues to serve an extremely wide range of environments.

User-facing changes and quality-of-life improvements​

Beyond platform support, 3.0.22 RC1 introduces several user-oriented touches worth calling out:
  • Dark palette for Qt UI — a native, integrated dark theme option makes the UI easier on the eyes and eliminates the need for third-party skins or custom DLL swaps.
  • Rename/move/delete while playing — this addresses an annoyance: safer file handling while a video is open, aligning VLC with how many modern media players behave on Windows.
  • Qt6 build support — future-proofs the GUI build pipeline and opens the door to better UI performance and platform integration in future backports or builds.
  • Disabled legacy decoders by default — this reduces the footprint of less-maintained third-party decoders in favor of a unified libavcodec pipeline, simplifying maintenance and hardening security posture.
These are the kinds of small improvements that improve daily use and reduce friction for regular users.

Deep-dive: codec, demuxer, and hardware decoding work​

For power users, the changelog entries under the hood are significant:
  • dav1d-all-layers option — dav1d is now given an option to output all spatial layers (useful for certain AV1 wrapped streams); this gives more control over multi-layer AV1 content.
  • Opus channel mapping fix — addresses regressions introduced in prior builds that could cause audio-channel misplacement in some MKV containers.
  • VideoToolbox fix for XVID MPEG-4 — on macOS, hardware decode paths for older XVID-based MP4 content are corrected.
  • ProRes 4:4:4:4 fix — improves compatibility with professional video content, aiding creators using older ProRes flavors.
  • FLAC picture handling and seeking logic fixes — important for music collectors and users with embedded cover art and complex FLAC files.
  • SFTP seeking fix on 32-bit OS — supports large-file seeking correctly on legacy 32-bit systems over SFTP.
The release also disables certain decoders (libdca, libmpeg2, liba52) by default in favor of libavcodec. That’s a pragmatic engineering choice: centralizing decoding through libavcodec reduces maintenance overhead and concentrates security hardening. Power users who depend on those older libraries should test after update and enable them explicitly if needed.

AMD Frame Rate Doubler: why it’s interesting (and why to be cautious)​

The changelog adds an AMD GPU Frame Rate Doubler option (Direct3D11 path). This is essentially a form of GPU-based frame interpolation — generating intermediate frames to achieve a smoother perceived frame rate.
Potential benefits:
  • Smoother motion in low-frame-rate content (e.g., 24 fps movies interpolated to 48/60 fps).
  • A perceived increase in fluidity for sports or animation.
Potential downsides and risks:
  • Frame interpolation changes artistic intent; films shot at 24 fps can look “soap-opera” smooth, which many viewers dislike.
  • Interpolation can introduce artifacts, ghosting, or halo effects — quality varies widely with algorithm and GPU implementation.
  • GPU-based features can be driver-dependent; behavior on different AMD driver versions may vary.
Recommendation: treat AFMF (frame rate doubler) as an experimental option. Test with specific content and drivers, and keep a conservative default (off) for general playback.

Stability and testing: RC1, nightly builds, and community reports​

A few months of nightly testing have shaped expectations for this release:
  • Community reports show the 3.0.x arm64 nightly builds sometimes delivered crashes or subtitle-related issues, particularly early on.
  • Several regressions fixed in 3.0.22 come from community bug reports and fuzzing projects, meaning many corner cases were addressed — but RC status implies further testing before broad deployment.
  • Users who need production stability (e.g., broadcasting, professional editing, or kiosk deployments) should prefer stable channel binaries and delay immediate adoption of RC builds.
If you’re curious to try the RC:
  • Keep a stable official 3.0.x release installed to fall back on.
  • Install the RC in a side-by-side folder or in a test VM.
  • Test the specific file types, codecs, and hardware acceleration paths you rely on (AV1/dav1d, Opus, ProRes, hardware decode).
  • Run stress tests: long-form playback, frequent seek/jump operations, subtitle toggling, and streaming to remote renderers.
  • Collect logs and file bug reports with detailed reproduction steps if you encounter regressions.

Security hardening: a notable focus​

Multiple reports indicate that this release contains an unusually large set of security fixes for a 3.0.x minor release. The maintainers’ work appears to include both proactive audit fixes and externally-reported vulnerabilities addressed via the project’s bug bounty and audit channels.
What to know:
  • The security work reduces attack surface across decoders and demuxers — the parts of VLC that historically attract CVE reports because they parse many complex container/codec formats.
  • Centralizing decoding through libavcodec (where possible) reduces the complexity of maintaining many separate decoder projects.
  • End users should still keep VLC updated; attackers frequently target outdated media libraries.
A caveat: some commentary about “the most security fixes ever” for this release appears in secondary coverage. While the overall tone of the maintenance work is clearly security-forward, treat grand claims about “the biggest security release” with caution until the project’s official release notes and security advisories are consulted.

Practical advice for WindowsForum readers​

For enthusiasts and regular Windows users, here’s a concise set of recommendations if you’re watching the 3.0.22 rollout:
  • If you run a Windows 11 on Arm device and want native performance, keep an eye on the stable 3.0.22 binaries once they’re published. Nightlies and RC builds can be useful for testing, but they may be less stable.
  • If you depend on VLC for critical tasks (lecture capture, live streams, or professional playback), wait for the final stable release and review the bug tracker for regressions related to your workflows.
  • If you want to try the RC now:
  • Install it in a test environment.
  • Test your typical media types (AV1, AV1+Opus MKVs, ProRes, encrypted streams).
  • Check hardware acceleration and CPU usage for your common content.
  • Avoid downloading unofficial “patched” builds from random sites. If the official binary isn’t available yet, compile from source only if you understand build dependencies and trust the build environment.

How to test the ARM64 build safely (step-by-step)​

  • Back up your VLC configuration folder (preferences, plugins) to a safe location.
  • Download or build the ARM64 RC in a separate directory (don’t overwrite your stable install).
  • Run VLC with the logging enabled (Tools > Messages) and note any warnings at launch.
  • Open representative files:
  • High-bitrate MP4/H.265, MKV with AV1+Opus, multi-track ProRes, and common subtitle formats (SRT, PGS, SSA).
  • Test hardware acceleration:
  • Check the Codec/Tools messages to verify hardware decode path (DXVA, D3D11, VideoToolbox, VA-API as applicable).
  • Monitor CPU usage and power draw during 30–60 minutes of playback.
  • Try file operations (rename/move/delete) on open files to confirm the new behavior.
  • If playing on a laptop, monitor thermals and battery drain against a stable baseline.
  • Report regressions with precise steps and logs to the VLC bug tracker.

Risks and limitations — what remains unresolved​

  • RC instability: by definition, release candidates can still contain regressions. Nightly reports show that some subtitle/seek problems and intermittent crashes happened in the past.
  • Driver/decoder variance: hardware-accelerated features vary by GPU, driver version, and OS. Expect differences in behavior across vendor stacks (AMD/NVIDIA/Intel).
  • Artistic concerns over interpolation: the frame-rate doubler is a feature that will be polarizing; it’s technically intriguing but not universally desirable.
  • Legacy support trade-offs: enabling XP compatibility and leaving old decoders available (even if disabled by default) maintains broad compatibility but increases maintenance complexity.
  • Security claims: while the release emphasizes security fixes, bold claims about “the biggest security update ever” warrant cautious interpretation until the official security advisory is published.

The strategic picture: VLC’s role in the Windows on Arm era​

This VLC update is noteworthy not because it changes how everyone watches their videos, but because it signals continued commitment to the cross-platform, open-source media stack at a time when Windows on Arm is maturing.
  • VLC supporting Arm64 natively removes one more friction point for users considering Arm-based Windows hardware.
  • The move reinforces a larger trend: developers and maintainers are prioritizing Arm builds to capture the efficiency gains of modern mobile-class silicon in laptops and 2-in-1s.
  • For the Windows on Arm ecosystem, mainstream apps like VLC becoming native reduces dependence on emulation and makes the platform more appealing for media-heavy users and creatives.
At the same time, VLC remains conservative: the update is a pragmatic maintenance release rather than an aggressive refactor. That will reassure users who prize reliability above novelty.

Conclusion​

VLC 3.0.22 RC1 is a practical, welcome refresh for a player that still occupies a central place in the media ecosystem. Official Windows ARM64 binaries signal the project's recognition of the Arm transition in Windows hardware, while the long list of bug fixes, decoder corrections, and security hardening improves reliability across platforms.
For mainstream Windows users, the most immediate benefits will be better native performance on Arm devices and a long-overdue native dark theme. Power users should appreciate the AV1/dav1d options, the ProRes/XVID fixes, and the demuxer stability work. Professional users should still hold out for the full stable release before migrating production systems.
The release candidate is not yet a finished consumer product — early testers should proceed carefully and help the project by filing good bug reports. But measured by the bar of pragmatic, high-impact maintenance, 3.0.22 RC1 is a solid, user-first step that keeps VLC relevant and robust as the Windows platform evolves.
Source: Windows Central New VLC update adds official support for Windows 11 on Arm and fixes support for Windows XP
 

Click to expand...
You must log in or register to reply here.
Back
Top