RAW10 Capture and GPU Debayer on Jetson: the Argus Bypass

When nvargus-daemon starts throwing failed to create capture session errors deep into a continuous recording run, the standard move is a daemon restart, and it usually works, for a while. On Jetson Orin fleets doing sustained high-fps capture, that workaround is known to degrade again after enough recording cycles. The pattern worth knowing for that situation is RAW10 capture and GPU debayer on Jetson: skip Argus and the Tegra ISP entirely, pull raw Bayer off the sensor over V4L2, and demosaic on the GPU with CUDA instead. This is not a first move. It’s what you reach for after the restart-and-hope pattern stops holding.

Key Insights

• The failure pattern that justifies this bypass is specific: failed to create capture session, socket/RPC dispatch errors, or zero-byte output files that recur across sustained recording sessions, not a one-time crash
• The real trigger is usually the encode-and-write-to-disk stage falling behind at high fps, not frame capture itself, it just surfaces as an Argus failure
• The replacement pipeline keeps everything zero-copy: V4L2 dmabuf (RAW10/RG10) into a CUDA debayer into NVENC, no CPU round trip
• FastVideo CUDA Debayer and CUVILib, the two established libraries for this, are commercially licensed, not free, not open source, and not bundled with JetPack
• Dropping Argus means reimplementing auto-exposure, auto-white-balance, and tone mapping yourself, and the GPU debayer now competes with any other GPU work for the same silicon

Why RAW10 capture and GPU debayer on Jetson become the fallback

Argus (nvarguscamerasrc, nvargus-daemon) is the right default on Jetson. It runs the Tegra hardware ISP, handling auto-exposure, auto-white-balance, denoise, and demosaic automatically, and most production camera pipelines should use it. We’ve written about getting Argus running correctly and debugging its common failure modes in our Argus driver setup guide. If your camera works with v4l2-ctl but Argus refuses to start, or the daemon deadlocks under load, those are usually fixable without abandoning the ISP path, and we cover the crash-versus-deadlock split and the JetPack 6 libnvscf CaptureScheduler regression in our nvargus crash and deadlock debug guide.

The bypass in this post is for a narrower and worse situation: you’ve already applied the point-release upgrade, you’ve already got a watchdog restarting the daemon on stall, and the pipeline still degrades under your specific workload. The pattern is consistent across reports of this failure mode: clean recording for the first several sessions, then Argus starts producing failed to create capture session on session start, or the socket between the client process and nvargus-daemon starts throwing RPC dispatch errors, or a recording completes but leaves a zero-byte file on disk. Restarting the daemon and the application recovers it, but only for a while, and the recurrence gets more frequent the longer the device has been running.

The important diagnostic point is that frame capture itself is rarely the bottleneck. The instability shows up during or right after the encode-and-write-to-disk stage at sustained high frame rates. Argus is the thing that visibly falls over, but it’s downstream pressure, not a capture-path bug, that’s putting it there. Once you’ve confirmed that (watchdog logs plus disk write timing are usually enough), the fix isn’t to debug Argus harder, it’s to remove it from the pipeline so there’s nothing left to fall over.

The bypass pipeline: V4L2 to CUDA to NVENC, zero-copy

The replacement architecture keeps the same zero-copy discipline that made Argus attractive in the first place, it just moves the ISP work off NVIDIA’s stack and onto one you own:

1. Capture raw Bayer directly from the sensor node over V4L2 as RG10 (RAW10), no ISP involved. This is the same raw path used to bring up a sensor before Argus is ever in the picture, v4l2-ctl and a bare v4l2src pipeline prove sensor, device tree, and CSI path all work before you build anything on top.
2. Keep the buffer as a dmabuf, not a CPU-mapped copy. The V4L2 capture must be configured for dmabuf export so the frame never round-trips through host memory before the GPU touches it.
3. Debayer on the GPU with a CUDA imaging library that operates on NVMM/dmabuf buffers directly. This is the step where FastVideo CUDA Debayer or CUVILib do the demosaic work, converting RG10 into a usable RGB or YUV frame without leaving GPU memory.
4. Hand the debayered frame to NVENC through the same NVMM zero-copy path Argus output would have used. If your encoder integration already expects NVMM buffers from nvarguscamerasrc, the encoder side of the pipeline barely changes, only what feeds it does.
5. Write to disk or stream out, same as before.

Stage	Argus path	Bypass path
Sensor read	V4L2 subdev, internal to Argus	V4L2 subdev, direct
ISP / demosaic	nvargus-daemon, Tegra ISP	CUDA debayer (FastVideo / CUVILib)
Buffer handling	NVMM, managed by Argus	NVMM/dmabuf, managed by your code
Encode	NVENC via nvarguscamerasrc output	NVENC, same zero-copy contract
Failure surface	nvargus-daemon, single process	Your capture + CUDA code, no daemon dependency

The tradeoff is visible in that last row. You’ve traded a single, opaque, NVIDIA-maintained daemon for a pipeline you own end to end, which means the specific failure mode you were chasing (Argus instability under load) goes away, but debugging responsibility for everything downstream of the sensor now sits with your team.

What you lose when you drop Argus, and who has to rebuild it

This is the part of the bypass that’s easy to underestimate in a planning meeting and hard to underestimate once you’re staring at a washed-out or green-tinted frame in the field. Argus isn’t just a demosaic step, it’s a full ISP, and every function it performs has to land somewhere else once it’s out of the pipeline.

ISP function (Argus path)	Who does it after the bypass
Demosaic	GPU CUDA debayer
Auto-exposure (AE)	Your own GPU/software control loop
Auto-white-balance (AWB)	Your own GPU/software implementation
Temporal noise reduction	Your own GPU/software implementation
Tone mapping	Your own GPU/software implementation

None of these are drop-in replacements. AE and AWB are closed-loop control problems, you need a metering strategy, a gain/exposure actuation path back to the sensor driver, and enough tuning to avoid hunting or flicker under changing light. Tone mapping and noise reduction are image-quality work that the Tegra ISP has had years of vendor tuning behind it, your first pass will not look as good, and getting it close takes real iteration time against real scenes, not a synthetic test chart.

There’s a second cost that’s easy to miss because it isn’t in the image quality column at all: the CUDA debayer now shares the GPU with anything else you’re running there, stitching, other CV processing, or inference. On Argus, ISP work happens on a dedicated hardware block and doesn’t touch your compute budget. On the bypass, it does. Budget GPU headroom for the debayer the same way you’d budget it for a model, because it is now competing for the same silicon.

Licensing reality: CUDA debayer is not free software

This needs to be said plainly because it gets glossed over in vendor conversations: FastVideo CUDA Debayer and CUVILib are commercial products. They are not open source, they are not bundled with JetPack or the Jetson SDK, and they are not free to deploy across a fleet. If a proposal for this architecture doesn’t include a line item for per-unit or per-fleet licensing of whichever debayer library you pick, that proposal is missing a real cost, not a rounding error.

The alternative, writing your own CUDA debayer kernel, is a legitimate option and some teams do it, but it is a real computer-vision and CUDA engineering project on its own, not a weekend task bolted onto a capture pipeline. Interpolation quality, edge artifacts, and performance at your target resolution and frame rate all have to be validated against real sensor output, not just a reference test pattern. Whether you buy a commercial library or build your own, the debayer step has a cost that has to be planned for; the only thing that changes is whether that cost shows up as a license fee or as engineering time.

There’s a cleaner way out of this entire tradeoff if it’s still available to you: choose a sensor module with an onboard ISP, so Argus (and this whole bypass question) never enters the design in the first place. The module emits already-processed frames, and neither the Tegra ISP nor a from-scratch software ISP is in your critical path. If you’re early enough in hardware selection that a sensor swap is on the table, it’s worth putting on the list before committing to either side of the Argus-versus-bypass decision.

Frequently Asked Questions

What causes nvargus-daemon to fail during sustained high-fps recording on Jetson?

In our experience the daemon itself is rarely the root cause. The trigger is usually the encode-and-write-to-disk stage falling behind at high frame rates, and that back-pressure surfaces as an Argus failure: failed to create capture session errors, socket or RPC dispatch failures, or zero-byte output files. Restarting nvargus-daemon and the application recovers the pipeline temporarily, but on some fleets it degrades again after a number of recording cycles.

Is FastVideo CUDA Debayer or CUVILib free or open source?

No. Both are commercial, closed-source libraries. Neither ships with the Jetson SDK or JetPack, and neither is free for production use. If you plan to deploy a fleet of devices running GPU debayer, per-unit licensing needs to be budgeted as a real line item, the same way you’d budget a sensor or a connector, not assumed to be included because it runs on Jetson.

Can you bypass the Argus ISP on Jetson and still get zero-copy capture into the encoder?

Yes, that is the point of the bypass. You capture raw Bayer over V4L2 as a dmabuf, debayer it on the GPU with a CUDA library that operates on NVMM buffers, and hand the result to NVENC without a CPU round trip. The zero-copy chain from sensor to encoder is preserved, you are only replacing what does the demosaic and ISP work, not adding a copy back to host memory.

What do you lose when you bypass Argus and capture raw V4L2 on Jetson?

You lose the entire Tegra ISP: demosaic, auto-exposure, auto-white-balance, temporal noise reduction, and tone mapping. All of that has to be reimplemented in GPU or software to reach comparable image quality. This is a real engineering project, not a configuration change, and it’s the main reason the bypass is a last resort rather than a default architecture.

Is there a way to avoid nvargus-daemon instability without building a custom GPU debayer pipeline?

Sometimes. If the instability is a known libnvscf CaptureScheduler deadlock, a JetPack point release upgrade or a watchdog that restarts the daemon on stall can resolve it without touching your capture architecture. The GPU debayer bypass is worth it only when that class of fix has been tried and the failure keeps recurring under your specific sustained-recording workload, or when a sensor swap to a module with an onboard ISP isn’t an option.

---

ProventusNova helps hardware startups solve embedded systems problems fast. Get camera pipeline and driver development done in two weeks.