- 1
Part 15 min readMy GSoC 2026 Project Overview
Starting Google Summer of Code 2026 with VideoLAN, teaching VLC to draw GPU-decoded frames without copying them through the CPU first. The series opener: who I am and the round-trip I'm here to delete.
Read this part - 2
Part 23 min readWeek 1: first patch written
Week 1 of my GSoC with VideoLAN: a first patch that changes nothing on purpose, an assumption that fell apart once I read the source.
Read this part - 3
Part 34 min readWeek 2: NVDEC the easy way first
Before porting NVDEC to Vulkan, I got it playing zero-copy through OpenGL first, so I have a known-good reference to compare against. Then a long time reading my mentor's branch.
Read this part - 4
Part 48 min readWeek 3: first light on the Vulkan path
An NVDEC frame decoded on the GPU, imported into Vulkan with no CPU copy, and drawn by libplacebo. It works, the 4K file plays with correct colors. Then I turned on Vulkan's validation layer and it flagged the code as illegal, the same code NVIDIA had been drawing.
Read this part - 5
Part 53 min readWeek 4: the green noise that proved the obvious fix was wrong
Last week's validation error said my image can't be both disjoint and dedicated at once. The obvious fix was to drop the dedicated part, so I did, and the color fell apart into green noise across the sky and the water.
Read this part - 6
Part 65 min readWeek 5: syncing the NVDEC copy and the render
I had to make CUDA's copy and libplacebo's render take turns over one image, using a single timeline counter shared across both APIs with no CPU copy.
Read this part - 7
Part 72 min readWeek 6: writing the frame sync into code
Last week I designed the handshake that keeps CUDA and the renderer from touching the same image at once. This week I wrote it, then spent most of my time making sure it was actually correct.
Read this part - 8
Part 86 min readWeek 7: making a software interop
Software video was the one thing my interop system could not handle, and it was needed to have the same interface for both types (software and hardware).
Read this part - 9
Part 95 min readWeek 8: reshaping the branch, then running out of hardware
A rebase from five commits to nine, and then the discovery that my machine cannot test VA-API at all
Read this part - 10
Part 107 min readWeek 9: what VA-API breaks that NVDEC did not
The hardware turned up this week, so I could finally read the VA-API interop properly instead of guessing at it. It gets its frames in a completely different way from the decoder I already have working.
Read this part - 11
Part 114 min readWeek 10: getting VA-API to produce frames and rethinking the contract
Started working on building the VA-API interop and successfully got H.264 video rendering. However, its synchronization and memory handling behave fundamentally differently from NVDEC, which means the core layer's design will need some contract changes to support both properly.
Read this part - 12
Part 1214 min readGSoC 2026 with VideoLAN Final Report: zero-copy GPU video in VLC
My GSoC work with VideoLAN is complete. Your graphics card decodes the video, and then VLC copies that frame off the card into system memory and straight back again before drawing it. Deleting that round trip was my Google Summer of Code with VideoLAN: what I built for NVDEC, VA-API, and software frames, what I didn't, and a summer of arguing with drivers.
Read this part
Ongoing Started May 2026 12 entries
GSoC 2026 with VideoLAN: teaching VLC to show GPU video without the copy
Engineering a zero-copy Vulkan interop pipeline for VLC's libplacebo renderer
I'm spending the summer with VideoLAN fixing a bottleneck in VLC. Right now, even when a video is decoded on the GPU, VLC copies the frames down to system memory and back up again just to draw them on the libplacebo video output through Vulkan. My project is to build a zero-copy hardware interop.
More to come - this journey is still in progress