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:

  1. Press Start Recording.
  2. OBS freezes.
  3. The webcam LED starts flickering on and off.
  4. 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:

  1. Recording start initializes the encoder and stalls the capture pipeline for a moment.
  2. That stall lets the webcam idle for two seconds → autosuspend fires → camera reset loop.
  3. 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 as ffmpeg_vaapi_tex. If you set the old ID you’ll get Encoder ID 'ffmpeg_vaapi_h264' not found in 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. vainfo showing only VAEntrypointVLD means no hardware encode; install mesa-va-drivers-freeworld from RPM Fusion.
  • OBS’s encoder ID is ffmpeg_vaapi_tex, not ffmpeg_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

  1. Webcam flickering on/off? Check /sys/bus/usb/devices/*/power/control on your camera and force it on with a udev rule.
  2. 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.

References

  1. How can I disable usb autosuspend for a given particular device or all usb — Unix & Linux SE
  2. Linux USB autosuspend — camera disconnects
  3. Mesa VA-API drivers (freeworld) — RPM Fusion
  4. obsproject/obs-studio — PipeWire screen capture issues (#11617, #11712)