Homebrew SysDVR-UVC - USB Video Class Sysmodule

[Insektaure]

SysDVR-UVC - USB Video Class Sysmodule​

This sysmodule presents the Nintendo Switch as a standard USB Video Class (UVC) webcam, allowing video capture on a PC without any client software.

Verified working end to end on Linux (ffplay, v4l2-ctl, OBS) and Windows (ffplay, OBS with caveats - see Latency below).

Tested on FW 22.1.0. Latest Atmosphere / Hekate.
Windows 10 1909 / Ubuntu 24.04 LTS.

Features​

• Driverless operation: enumerates as a standard USB webcam (Linux uvcvideo, Windows usbvideo.sys)
• H.264 passthrough: streams the native H.264 video from the Switch's game recording service (grc:d) - no on-console transcoding
• 720p @ 30fps: native output of Nintendo's encoder
• Low latency: tuned for live capture (low-delay SPS, minimal UVC payload headers, render-on-arrival)

Requirements​

• Nintendo Switch with Atmosphere, HOS 5.0 or newer
• A game that supports video capture (recording icon visible)
• A data-capable USB-C cable
• The original SysDVR sysmodule must NOT be installed/enabled: grc:d only supports one client, and both sysmodules also compete for usb:ds. Running both crashes the console at boot.

Install​

• Unzip at the root of your SD card
• Activate the sysmodule with an overlay (e.g. ovlSysmodules) or any other sysmodule manager
• No need to reboot as sysmodule can be enable / disable on-the-fly
• Connect to PC, open the camera "SysDVR-UVC Capture" with a capture software (FFplay from FFMPEG, OBS, ...)

Usage​

1. Connect the Switch to the PC via USB-C
2. Launch a game that supports video capture
3. The PC sees a webcam named "SysDVR-UVC Capture" (VID 046d, PID 0825)

Note: when an application opens the stream, expect up to ~2 seconds of black/garbage before the first picture - that is the Switch encoder's keyframe interval and cannot be shortened.

Linux​

One-time setup: your user must be able to read video devices:

sudo usermod -aG video $USER # then log out and back in

# Or, to grant access immediately without logging out (resets on unplug/reboot):
sudo chmod a+rw /dev/video2

The device creates two nodes: capture + UVC metadata. The numbers are not fixed - the kernel assigns /dev/videoN in detection order, so on a machine with no other camera the Switch gets video0/video1, while a laptop with a built-in webcam typically yields video2/video3.

Find yours with:

v4l2-ctl --list-devices

Look for "SysDVR-UVC Capture" and use its first node (the capture node), or let apps pick "default".

The examples below assume /dev/video2 - substitute your own node.

# Low-latency viewer (this is the reference pipeline)
ffplay -fflags nobuffer -flags low_delay -probesize 32 -analyzeduration 0 \
-framedrop -f v4l2 -input_format h264 -i /dev/video2

# Record raw H.264
v4l2-ctl -d /dev/video2 --stream-mmap --stream-count=300 --stream-to=out.h264

OBS on Linux: add a "Video Capture Device (V4L2)" source, Device"default", Video Format "H.264", 1280x720 @ 30.
Works with low latency.

Windows​

ffplay -fflags nobuffer -flags low_delay -probesize 32 -analyzeduration 0 ^
-framedrop -rtbufsize 32M -f dshow -i video="SysDVR-UVC Capture"

Note: Windows Media Foundation apps (the Camera app, browsers, Teams) do not support H.264 UVC cameras at all - this is a Windows limitation.
DirectShow apps (ffplay, VLC, OBS) work.

Latency​

The stream itself is low-latency by construction (~140 ms to first decoded frame, real-time 33 ms pacing after - measured).

What you experience depends on the player:

• ffplay: fast only with the flags shown above. Plain ffplay buffers its stream-probing backlog and stays a constant 1-2 s behind on any live source - that is ffplay behavior, not the device.
• OBS Linux: fast (V4L2 plugin).
• OBS Windows: a constant ~1-2 s delay caused by OBS itself: its DirectShow H.264 decoder is opened with auto frame-threading and no low-delay flag, which structurally delays output by up to 15 frames. Tracked upstream (obsproject/obs-studio#13462). Until fixed, the reliable workaround is running the tuned ffplay window and adding it to OBS via Window Capture. Always set the source's "Buffering" to "Disable" - "Auto" silently force-buffers H.264 devices.

Audio​

There is none, and there cannot be: standard USB audio (UAC) requires an isochronous endpoint, and the Switch's usb:ds service cannot build a configuration containing one.

Workaround: Bluetooth audio (A2DP sink)​

The Switch can output audio over Bluetooth (HOS 13.0+), and the PC can act as the receiver (an A2DP sink, i.e. pretend to be headphones).
This works on Linux and on Windows 10 since version 2004.

Caveats: Bluetooth adds its own latency (typically 100-200 ms with SBC), so audio will trail the low-latency video slightly.
While Bluetooth audio is active the Switch limits you to two wireless controllers and disables local wireless play - that is a console-side restriction.

Technical Details​

• UVC 1.5, VideoControl + VideoStreaming interfaces, H.264 frame-based format over a bulk endpoint in alternate setting 0
• Codec: H.264 High profile, level 3.2, 1280x720 @ 30 fps, pic_order_cnt_type=2 (no frame reordering possible)
• The stream from grc:d carries no parameter sets; the sysmodule injects SPS/PPS before keyframes. The injected SPS extends Nintendo's original with VUI timing info and max_num_reorder_frames=0 so decoders open in low-delay mode
• UVC payload headers are the minimal 2 bytes (no PTS/SCR): hosts render frames on arrival instead of scheduling against an uncorrelatable device clock

Limitations​

1. H.264-only: apps that cannot consume H.264 webcams will not show video (notably all Windows Media Foundation apps). MJPEG cannot be offered: grc:d outputs pre-encoded H.264, there are no raw frames.
2. Game support: only games with video capture enabled produce frames. On static screens grc:d skips frames entirely - the picture appears frozen until on-screen content changes. Both are console-side behavior.
3. No audio (see above).
4. No dock mode while streaming (USB-C is used for data).
5. Exclusive: incompatible with the original SysDVR sysmodule and any other grc:d client.

Troubleshooting​

• Device not in lsusb at all: check the cable is data-capable, the sysmodule is installed, and no other grc:d / usb:ds sysmodule is present. Check /atmosphere/crash_reports/ and /atmosphere/fatal_errors/ on the SD card for fresh files.
• Enumerates but no /dev/video (Linux): permissions (are you in the video group?) or a descriptor regression - sudo dmesg will show uvcvideo parse errors.
• Black picture in OBS: wrong node selected (the UVC metadata node) - use Device "default", Video Format H.264.
• Stream opens but freezes/lags: read the Latency section

Credits​

• Based on SysDVR by exelix11
• EP0 handling modeled on Atmosphere's ams::usb::DsInterface
• libnx by the switchbrew team

Github : https://github.com/Insektaure/SysDVR-UVC-Capture

 

[hippy dave]

Smart idea, nice job!

 

[eyeliner]

Can't you use an audio cable and plug it in to the mic port of the computer instead of using Bluetooth?
I never used streaming on the Switch, so I don't know.

 

[Insektaure]

Can't you use an audio cable and plug it in to the mic port of the computer instead of using Bluetooth?
I never used streaming on the Switch, so I don't know.

You definitely could do that on a desktop computer with a "line in" port instead of using BT.

Don't know about laptop since you have to use a TRS cable, if there is any audio jack (laptop tends to get rid of these to cut cost or to shrink the laptop thickness).

Choice is yours. BT is widely available so it's a decent "universal" option.