Why Your Webcam Uploads Are Huge on Fedora

I record on Riverside for podcast sessions. Same webcam, same resolution, same settings, same machines (dual booted). A 42 minute session on Windows came out to 3GB. A 44 minute session on Fedora came out to 7GB.

Same Logitech Brio. Same 1920x1080 request. Same frame rate. More than double the data.

If you've noticed your Linux machine chewing through way more bandwidth than Windows for the exact same video call length, this is probably why.

WARNING: this one's Fedora-specific, the cause and fix are different if you're on Ubuntu or another distro.

Rule out the obvious first

Before touching anything Chrome specific, confirm it's actually an OS problem and not a network problem. If you have a dual boot setup or a second machine on the same connection, that's your control group. Same router, same cable, same ISP, only the OS changes. If upload size still differs wildly, the network is cleared and you're looking at software.

The instinct to check WebRTC internals is right, but it's the wrong tool for a fast check

chrome://webrtc-internals is where most guides point you, and it will eventually get you the answer. But it needs an active call running while the tab is open, and if the peer connection was created before you opened that tab, or you export a dump after the call ends, you get an empty stats object and nothing to work with.

Skip that overhead. Check chrome://gpu instead. No call needed. Search the page for "Video Encode." You'll see one of two things:

Hardware accelerated = your GPU is doing the work
Software only, hardware acceleration unavailable = your CPU is doing the work, which can result in substantially higher bitrates depending on the browser's encoder configuration.

That single line was the whole diagnosis.

Windows: hardware accelerated.
Fedora: software only.

Mystery solved.

Why Chrome was using software encoding on Fedora

This part surprised me. It's not a missing driver in the "you forgot to install something" sense. It's a licensing decision baked into the distro.

Fedora's stock Mesa build ships with H.264 encode support deliberately stripped out, because H.264 is patent encumbered and Fedora's base repos have to stay clean of that. The hardware support is there on the GPU (my RX 580 has had VCE encode capability since Polaris), Mesa just isn't allowed to expose it out of the box.

RPM Fusion's "freeworld" build of the same driver has it re-enabled. That's the whole fix, in theory:

sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing

In practice, expect at least one dependency fight along the way. If you have Steam or anything else pulling in 32-bit Mesa packages, or if Fedora's updates repo has moved slightly ahead of what RPM Fusion has rebuilt, the swap will fail with a wall of "none of the providers can be installed" errors that look scarier than they are. Running a full sudo dnf update --refresh first to get your core Mesa packages internally consistent, then retrying the swap, cleared it for me. Worst case, sudo dnf install mesa-va-drivers-freeworld --allowerasing as a direct install (rather than a swap) will resolve conflicts a swap won't.

Verify it worked with:

vainfo

Before the fix, my output only listed MPEG2, JPEG, and video processing. No H.264 anywhere. After the fix:

VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice

EncSlice is the entrypoint that matters. That's hardware encode, present and accounted for.

The driver fix alone isn't enough. Chrome needs to be told to use it.

This is the step that isn't in most guides anymore, because it changed recently. Older instructions point you to chrome://flags/#enable-webrtc-platform-encoder. That flag is gone. As of Chrome 131, hardware video encode on Linux moved out of the flags UI and became a launch-time feature flag instead:

google-chrome --enable-features=AcceleratedVideoDecodeLinuxZeroCopyGL,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder

Quit Chrome completely first, since GPU capability detection happens once at process startup, not live. Then launch with that flag and recheck chrome://gpu.

If you want it permanent instead of typing that every time, edit the .desktop launcher so the flag is baked into how Chrome starts:

sudo sed -i 's|Exec=/usr/bin/google-chrome-stable %U|Exec=/usr/bin/google-chrome-stable --enable-features=AcceleratedVideoDecodeLinuxZeroCopyGL,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder %U|' /usr/share/applications/google-chrome.desktop

Check your actual Exec= line first, since the binary path can vary, and adjust the pattern to match before running it.

This isn't Riverside specific

Riverside is what surfaced it for me, but the actual cause lives at the OS and browser level, not in Riverside's code. Anything doing WebRTC video capture in Chrome on Linux, Zoom's web client, Google Meet, StreamYard, other recording platforms, is subject to the same fallback. If you're on Fedora (particularly with AMD GPUs) the stock Mesa packages intentionally omit patented H.264 VA-API support, causing Chrome to fall back to software encoding unless you install the RPM Fusion freeworld drivers. Other Linux distributions, including Ubuntu, can also fall back to software encoding, but the causes and fixes differ and aren't generally due to the same Mesa packaging decision.

The fast diagnostic path, if you just want the checklist

chrome://gpu, search "Video Encode." If it says software only, that's your answer.
vainfo in a terminal. If H.264 doesn't show VAEntrypointEncSlice, your driver doesn't expose hardware encode yet.
Install the appropriate VA-API driver for your GPU. On Fedora with AMD GPUs, that's typically mesa-va-drivers-freeworld. Intel systems use intel-media-driver instead.
Confirm vainfo now shows EncSlice for H.264.
Relaunch Chrome with --enable-features=AcceleratedVideoDecodeLinuxZeroCopyGL,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoEncoder.
Recheck chrome://gpu. It should now say hardware accelerated.

Five minutes of terminal work, and your next 40 minute recording session goes back to being 3GB instead of 7.