OBS Freezes and Webcam Flickers When Recording on Fedora 44
TL;DR: Two independent bugs were stacking on each other: (1) USB autosuspend was resetting my webcam mid-recording, and (2) OBS had no hardware video encoder available, so it was encoding with the CPU. Fixing both stopped the flicker and the freeze.
The symptom
In OBS Studio, with a scene containing a Screen Capture (PipeWire) source and a Logitech webcam:
- Press Start Recording.
- OBS freezes.
- The webcam LED starts flickering on and off.
- Nothing recovers until you kill OBS.
The freeze only happened when I hit record — previewing was fine. And it only happened when the webcam was in the scene.
Environment
Fedora 44, kernel 7.1.6-201.fc44.x86_64
OBS Studio 32.1.1
GPU: AMD Radeon RX 6600 XT (Navi 23)
Webcam: Logitech Webcam C270 (USB 046d:0825)
Wayland session, PipeWire audio/video
Finding bug #1: the flicker is the camera resetting
The LED flicker is a dead giveaway. That’s the camera dropping off the USB bus and re-enumerating. The kernel logs it as a device reset:
$ journalctl -k | grep -i usb
Aug 07 06:58:17 fedora kernel: usb 3-3: reset high-speed USB device number 2 using xhci_hcd
Aug 07 06:58:30 fedora kernel: usb 3-3: reset high-speed USB device number 2 using xhci_hcd
Aug 07 06:58:57 fedora kernel: usb 3-3: reset high-speed USB device number 2 using xhci_hcd
Aug 07 07:01:30 fedora kernel: usb 3-3: reset high-speed USB device number 2 using xhci_hcd
Each reset line is one on/off blink. Now, why is the kernel resetting a camera that’s in active
use? Check the device’s power management:
$ cat /sys/bus/usb/devices/3-3/power/control
auto
$ cat /sys/bus/usb/devices/3-3/power/autosuspend
2
power/control = auto with a 2-second autosuspend timeout. That’s the culprit. When recording
starts, OBS briefly stalls the capture path (see bug #2), the camera sits idle for two seconds,
the kernel suspends it to save power, and resuming a suspended camera that’s mid-stream shows up
as a reset. The camera toggles on and off in a loop, jamming OBS’s capture thread.
This is a well-known class of bug — UVC webcams don’t always survive autosuspend, and there are many reports of webcams doing a disconnect/reconnect loop under Linux power management.
Fix #1: disable autosuspend for the camera only
Don’t disable autosuspend globally (usbcore.autosuspend=-1) — that costs power on every USB
device. Target just the camera with a udev rule, which also survives reboots and re-plugging:
$ cat /etc/udev/rules.d/90-webcam-c270-no-autosuspend.rules
# Disable USB autosuspend on the Logitech Webcam C270 (046d:0825).
# Autosuspend suspends the camera after ~2s idle, causing a reset loop
# ("usb ...: reset high-speed USB device") when OBS/recording stalls the
# stream, which makes the webcam LED flicker on/off and freezes OBS.
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="0825", ATTR{power/control}="on"
Reload udev rules and apply it to the already-connected device immediately:
$ sudo udevadm control --reload-rules
$ echo on | sudo tee /sys/bus/usb/devices/3-3/power/control
on
$ cat /sys/bus/usb/devices/3-3/power/control
on
Find your camera’s vendor/product IDs with lsusb and substitute them into the rule.
Finding bug #2: OBS couldn’t use the hardware encoder
Fixing the flicker should remove the LED toggling, but why did OBS freeze in the first place? The OBS log had the answer:
FFmpeg VAAPI H264 encoding not supported
My GPU (RX 6600 XT) has a dedicated hardware H.264 encoder, but OBS couldn’t use it. Without a hardware encoder, OBS fell back to software encoding — in my config, the single-threaded OpenH264 encoder:
Available Encoders:
- ffmpeg_openh264 (OpenH264)
So the picture became clear:
- Recording start initializes the encoder and stalls the capture pipeline for a moment.
- That stall lets the webcam idle for two seconds → autosuspend fires → camera reset loop.
- Meanwhile the CPU is pegged by single-threaded software encoding, so when the capture thread jams on the reset camera, OBS freezes.
Remove either failure and the system recovers; fix both and it’s solid.
Fix #2: the Fedora encode-driver gotcha
The kernel driver is there and VA-API works — but the driver that ships by default only supports decode:
$ vainfo
Driver version: Mesa Gallium driver 26.1.5 ... (radeonsi, navi23 ...)
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileAV1Profile0 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
Every profile is VAEntrypointVLD (decode only). No H.264, no HEVC, and crucially no
VAEntrypointEncSlice (encode). On Fedora, the VA-API driver that ships in the default repos is
decode-only; the encode-capable build lives in RPM Fusion:
$ sudo dnf install mesa-va-drivers-freeworld
(RPM Fusion was already configured on my machine. If it isn’t on yours, add the free/nonfree repos
first.) Now vainfo shows what we actually want:
$ vainfo | grep -E 'H264|HEVC'
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice <-- encode!
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
Fix #3: switch OBS to the hardware encoder
OBS → Settings → Output → Advanced → set the Streaming and Recording encoders to
FFmpeg VAAPI H.264 (or edit the profile’s basic.ini:
[AdvOut]
Encoder=ffmpeg_vaapi_tex
RecEncoder=ffmpeg_vaapi_tex
Gotcha: older OBS versions and many online guides use the encoder ID
ffmpeg_vaapi_h264. Current OBS registers it asffmpeg_vaapi_tex. If you set the old ID you’ll getEncoder ID 'ffmpeg_vaapi_h264' not foundin the log. Check your OBS log under “Available Encoders:” for the exact name before hand-editing configs.
Verifying the fix
$ cat /sys/bus/usb/devices/3-3/power/control
on
$ vainfo | grep H264High
VAProfileH264High : VAEntrypointEncSlice
And an end-to-end hardware encode test (this is the exact path OBS’s VAAPI encoder uses):
$ ffmpeg -y -f lavfi -i testsrc=duration=2:size=1920x1080:rate=30 \
-vf format=nv12,hwupload -c:v h264_vaapi -vaapi_device /dev/dri/renderD128 \
-b:v 6M -f mp4 /tmp/vaapi_test.mp4
$ ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,width,height /tmp/vaapi_test.mp4
codec_name=h264
width=1920
height=1080
On the next OBS start the log shows:
VAAPI: API version 1.23
FFmpeg VAAPI H264 encoding supported
- ffmpeg_vaapi_tex (FFmpeg VAAPI H.264)
No more usb ...: reset high-speed USB device lines while recording, no flicker, no freeze.
Gotchas (learned the hard way)
-
USB autosuspend resets the webcam mid-stream. A 2-second idle during recording start is
enough to trigger it. Fix it with a per-device udev rule, not a global
usbcore.autosuspend=-1. -
Fedora’s default VA-API driver is decode-only.
vainfoshowing onlyVAEntrypointVLDmeans no hardware encode; installmesa-va-drivers-freeworldfrom RPM Fusion. -
OBS’s encoder ID is
ffmpeg_vaapi_tex, notffmpeg_vaapi_h264. Old guides set the wrong ID; read “Available Encoders:” from your OBS log first. -
AV1 is still decode-only over VA-API on this card/driver (
VAProfileAV1Profile0: VLD); use H.264 or HEVC for recording. - This is not the PipeWire-portal crash bug (OBS crashing when you select a capture source), which was fixed upstream. If you only freeze on record start with a webcam in the scene, check your USB power settings and your encoder first.
- The OBS screen-capture source itself was a red herring — the trigger was that starting recording perturbs both the capture path and the encoder at the same moment. The same pair of bugs will bite with any webcam source.
The two-line summary
-
Webcam flickering on/off? Check
/sys/bus/usb/devices/*/power/controlon your camera and force itonwith a udev rule. -
OBS freezing because it’s encoding with the CPU? Install
mesa-va-drivers-freeworld(Fedora) and switch OBS to the FFmpeg VAAPI H.264 encoder.