VLC (PPSA85300)

[babyhuey]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

VLC (PPSA85300)

Content version tested

0.4 (catalog release, a libvlc 3.0.24 port; source ZiZc3/VLC)

AnyPS5 commit

main a3aeaf8

System tested

• Windows: Windows 11 Pro 25H2, RTX 3080 (NVIDIA 591.86), WinLibs GCC 15.2.0 r7, Release
• Linux: Ubuntu 24.04, GCC 13, headless (SDL offscreen driver)

Furthest point

First-run setup page (no interactive input tested)

What is shown

On Windows it starts and renders at about 81 fps. The setup page shows only its background: a brown-to-black gradient and the four page dots. The text, buttons, hints and the VLC logo are missing. VLC's log reports 0 of 486 imports unresolved and RADV on Vulkan 1.4, with no load errors. No throw, NotImplemented or access violation appears in 60 s.

Current blocker

Updated 2026-10-14 (main e736e5b):

1. The fixed base at 0x400000 from Ruffle, VLC and XPSemu read their GOT at a fixed 0x400000 base from app0/imports.txt and fault once all imports load #4013: --windows-fixed-base and --linux-fixed-base (feat(relinker): load Linux executables at a fixed base #4593) are both merged. Without it the title faults at once.
2. AGC: VLC (PPSA85300) draws only its background; the logo and text draws show nothing although their storage images hold the texels #5731: the logo and text draws show nothing. YossiYad traced it to the mesh-path draw-entry cache reusing the first draw's index buffer for ImGui's later draws. It also reproduces on Linux with RADV.

How it was run

The catalog eboot.bin (and sce_module libraries) unwrapped and relinked with --windows --registry --windows-fixed-base 0x400000, run from a folder with app0 and an empty data folder, 40 to 90 s per run.

[babyhuey]

Update 2026-10-18: #5731 is fixed by #5791. On Windows 11 (RTX 3080, WinLibs GCC 15.2), main 5bf2e13, VLC 0.4 relinked with --windows --windows-fixed-base 0x400000 runs the full 60 s at about 120 fps and draws the whole first page: the cone logo, "Welcome to VLC", "Choose your language", the 4x4 language grid with every script (Latin, Arabic, Cyrillic, Japanese, Korean, Chinese), the page dots and the Continue/Skip prompts.

Without --windows-fixed-base it still stops at startup with an access violation reading 0x3a2b2c8, which is #4013: VLC reads its GOT at a fixed 0x400000 base, so it needs --windows-fixed-base 0x400000 (#4140) or, on Linux, --linux-fixed-base 0x400000 (#4593) when it is relinked. No other blocker is known on Windows.

[wachi35676]

Update on main 07377573f (Windows 11, RTX 5070 Ti, WinLibs GCC 15.2.0, Release), VLC 0.4.6 from the author's release, relinked with --windows-fixed-base 0x400000.

VLC now goes past "Presents" and plays local media from app0/media, with correct picture and audio:

• H.264 + AAC MP4: Big Buck Bunny 320x180 (Blender Foundation, CC-BY), cut to 40 s. It is decoded by Videodec2 (ps5vdec: 100 access units in, 100 pictures out, 0 errors). I checked the audio by cross-correlating the captured output against an ffmpeg decode.
• VP9 + Opus WebM (a transcode of the same clip): plays through the Videodec2 VP9 path.

No stop in any run. The only issue seen is net: no /dev/urandom: HTTPS won't work, which #6541 fixes (net: /dev/urandom ok in 3 of 3 runs with it).

AI-assisted: yes (Claude Code); results above were run on this machine.

[babyhuey]

Update 2026-10-19: #6541 (fopen of /dev/random and /dev/urandom) is merged. On Windows 11 (RTX 3080, WinLibs GCC 15.2), main 64a9caa62, VLC 0.4.6 from the catalog, relinked with --windows --registry --windows-fixed-base 0x400000: its log now has net: /dev/urandom ok (no no /dev/urandom line), the first page draws completely, and it runs the full 60 s at about 119 fps with no fault. Without --windows-fixed-base it still faults at start-up as before (#4013).