Sometimes the best solutions come from looking at hardware through a different lens. NVIDIA’s DGX Spark was designed as an entry-level AI development platform, but its combination of dual 200G ConnectX-7 NICs and Blackwell GPU makes it surprisingly well-suited for something completely different: professional broadcast infrastructure.
I’ve converted a $3,000 DGX Spark into a fully functional SMPTE ST 2110 node capable of receiving raw uncompressed video and audio, performing GPU-accelerated encoding, and publishing directly to Cloudflare’s Media over QUIC Transport (MOQT) relay—all with sub-second end-to-end latency.
This Demo Requires a Chrome based browser.
TL;DR #
A $3K NVIDIA DGX Spark can function as a complete broadcast ingest-to-CDN appliance. It receives uncompressed ST 2110 video and audio via its dual 200G ConnectX-7 NICs, processes raw YUV422 directly on the Blackwell GPU, encodes to ABR, and publishes to Cloudflare’s MOQT relay—all with sub-second latency. No RiverMax required. This same approach works for HLS/DASH delivery. Small form factor, low cost, minimal points of failure.
The Hardware Opportunity #
The DGX Spark ships with specifications that broadcast engineers would typically pay significantly more to achieve:
- Dual ConnectX-7 200GbE interfaces — More than enough bandwidth for multiple uncompressed ST 2110-20 video and ST 2110-30 audio streams
- Blackwell GPU — Native YUV422 processing directly on the GPU, plus hardware NVENC encoding
- Compact form factor — Small enough for deployment in tight spaces, production trucks, or edge locations
- Low power consumption — Practical for venues where power and cooling are constrained
What NVIDIA intended as AI development connectivity becomes broadcast-grade network capacity. What they intended for model training becomes real-time video processing and encoding.
Architecture Overview #
The pipeline flows from left to right:
- Source: For this demo, I’m using Netflix’s Meridian test content—a well-established reference for evaluating video pipelines. The file is decoded and transmitted as raw ST 2110-20 video (converted from YUV420 to YUV422 for broadcast compatibility) and ST 2110-30 audio
- Ingest & Processing: The DGX Spark receives these uncompressed streams via its ConnectX-7 interface. The Blackwell GPU ingests the raw YUV422 data directly—no CPU-side color space conversion or memory copies required
- Encoding: The GPU performs ABR encoding, generating multiple quality tiers for adaptive delivery
- Delivery: Encoded streams publish via MOQT to Cloudflare’s relay infrastructure
- Playback: End users watch through a standard web browser running an MOQT player
The result: true broadcast-quality ingest to global CDN delivery, with end-to-end latency under one second.
A Note on RiverMax #
This implementation deliberately does not use NVIDIA’s RiverMax SDK. While RiverMax is NVIDIA’s official solution for ST 2110 workflows and offers tight integration with their hardware, I wanted to demonstrate that the DGX Spark’s ConnectX-7 NICs are capable ST 2110 endpoints using alternative software stacks. As far as I’m aware, RiverMax isn’t currently available for the DGX Spark, and this also eliminates having to pay licensing. This opens the door to make innovating in the broadcast and AI space much more attainable.
Why This Matters #
Traditional broadcast-to-streaming workflows involve a cascade of specialized equipment: SDI or 2110 routers, dedicated frame synchronizers, standalone encoding appliances, and origin servers. Each component adds cost, latency, and failure modes. Coordinating between vendors and troubleshooting across system boundaries consumes engineering time.
The DGX Spark approach collapses this chain. A single compact device handles ingest, encode, and publish. The attack surface shrinks. The points of failure reduce. The budget drops dramatically.
And the latency story is compelling: sub-second glass-to-glass from a professional 2110 source to a web browser anywhere in the world. That’s competitive with traditional broadcast contribution links, but delivering to consumer devices over the public internet.
For on-premises deployments—sports venues, concert halls, corporate campuses, houses of worship—this architecture enables direct CDN publishing without backhauling to a central facility. The stream originates at the edge, exactly where the content is captured.
Beyond MOQ: HLS and DASH #
While I’m currently publishing to Cloudflare’s MOQ relay for the lowest possible latency, this same approach works equally well for conventional adaptive bitrate delivery. Swap the output stage to generate HLS or DASH segments, push them to object storage or a CDN origin, and you have a complete on-prem encoding solution.
The GPU handles the ladder encoding efficiently, and the high-bandwidth NICs ensure you’re never bottlenecked on output capacity—even when publishing multiple quality tiers simultaneously.
What’s Next #
I’m continuing to refine the 2110 receive pipeline and exploring tighter PTP synchronization for frame-accurate work. The Blackwell architecture opens up possibilities beyond encoding—the same GPU that processes YUV422 could perform real-time graphics insertion, audio processing, or AI-driven production automation without additional hardware.
The broader point is that the economics of broadcast infrastructure are shifting. Hardware designed for one purpose often excels at another. Sometimes a $3,000 AI developer kit is exactly what professional video production needs—and with the right software stack, it can outperform equipment costing ten times as much.
Let’s Talk #
If you’re exploring ST 2110 workflows, low-latency streaming architectures, or looking to modernize your broadcast infrastructure without the traditional price tag, I’d be happy to discuss what might work for your environment. Whether you’re a broadcaster evaluating edge encoding options, a venue looking to simplify your streaming stack, or just curious about how this all fits together—feel free to reach out. You can find my contact information in the author section above.