Live dealer craps is technically the most demanding game in the online casino streaming stack. Roulette streams a single fixed-camera view of a wheel spin. Blackjack manages turn-by-turn card interaction with visible card state. Craps requires multiple simultaneous camera angles, real-time dice outcome detection, immediate synchronization to every connected player, and a betting interface that must lock and update before the next roll sequence begins. Getting it right requires deliberate decisions at the infrastructure level — camera placement, encoding protocol, game state architecture, and CDN configuration — each of which has direct effects on what the player experiences at the table.
This is a breakdown of the systems that make a live dealer craps stream work and the choices operators make at each layer.
Building the studio infrastructure for a craps broadcast
A full-size craps table runs to roughly 12 feet in length with multiple distinct betting zones and two dice in play. No single fixed camera covers the game adequately. Professional live craps studios use a minimum of three cameras: one overhead to capture the full table layout and dice landing area, one side-angle to show the shooter and provide depth of field, and one close-up positioned above the pass line to capture dice outcomes with enough resolution for automated outcome detection.
The camera hardware runs on broadcast-grade SDI interfaces rather than consumer connections. SDI provides a locked, zero-jitter signal that HDMI and USB connections can’t reliably deliver over cable runs beyond a few metres — an important distinction when the signal is travelling from multiple camera positions to a central production encoder. The signal from each camera feeds into a hardware encoder or production switcher before the stream enters the software pipeline.
Lighting for dice detection is a specific engineering consideration. Automated pips detection — where the platform reads dice outcomes directly via computer vision rather than waiting for dealer input — requires controlled, diffuse lighting without glare or shadow on the dice faces. Uncontrolled specular reflection from a glossy die surface is one of the more common failure modes in automated outcome detection, and studios address it with a combination of overhead diffuse panels and adjustable LED fills.
Encoding the stream for minimum-latency delivery
The choice of streaming protocol defines the latency floor for the experience. HTTP Live Streaming — developed by Apple and standardised by the IETF — achieves strong device compatibility and handles variable network conditions through adaptive bitrate switching, but introduces 3–7 seconds of latency at minimum. For a game where the next roll can follow within 30 seconds of the previous result, that delay creates a perceptible gap between the dealer’s visible action and the player’s interface response.
WebRTC achieves sub-second latency by maintaining persistent peer-to-peer connections rather than delivering segmented HTTP chunks. The tradeoff is infrastructure complexity: WebRTC requires signalling servers to manage each player’s connection, and scaling to thousands of simultaneous players means managing a substantially larger number of real-time sessions than HLS’s CDN-friendly chunk delivery requires. Most live craps operators address this by using WebRTC for video delivery and a separate WebSocket channel for game state events — so even if video latency varies by a few hundred milliseconds across connections, the interface update that matters most (the dice outcome lock) reaches the player in under 200 milliseconds.
Synchronizing game state across a distributed player pool
The dice roll is the central synchronization event in every live craps session. When the dice land, the platform must capture the outcome via computer vision or dealer entry, validate the result, push the game state update to all connected players, and lock the betting interface to prevent wagers from being placed against a known outcome. All of this must happen before the outcome is visually visible to players who haven’t yet received the corresponding video frame.
The ordering is enforced at the server level. The game state engine writes the outcome to the session record and broadcasts the betting lock before releasing the outcome event to player interfaces. Players who receive the state update before the corresponding video frame will see the result before the video catches up — which is why some operators introduce a brief deliberate hold on the outcome broadcast to keep visual and interface synchronization aligned.
For US players evaluating platforms, the responsiveness of this synchronization pipeline is one of the practical differences between operators. Reviews covering online craps for US players typically assess interface latency and how quickly outcome events register across connection types — both are direct reflections of how well the game state architecture is implemented.
Distributing the feed across US time zones
US player traffic on live craps tables concentrates in two clusters: East Coast evening sessions and West Coast sessions running roughly two hours behind. A live craps stream originating from a European or Central American studio reaches East Coast players with approximately 80–120 milliseconds of network latency under normal conditions, and West Coast players with 100–160 milliseconds.
CDN infrastructure addresses this by replicating HLS stream segments across edge nodes positioned closer to US player populations, reducing the geographic distance between the origin stream and each player’s connection. For WebRTC traffic, the equivalent involves regional relay servers — TURN and STUN infrastructure — that handle connection establishment from locations geographically closer to the player than the originating studio. The practical result is that a player in Seattle and a player in Miami can watch the same live table with similar perceived performance despite the studio being in Riga or San José.
Protecting the distributed stream from unauthorized access is a parallel infrastructure concern. The same principles that govern how teams secure sensitive video content during distribution apply directly to live casino feeds: stream encryption, authenticated playback sessions, and token-based access control that prevents unauthorized viewers from accessing the feed without a valid, active session.
Auditing integrity in a live craps environment
Live dealer craps is not RNG-based — outcomes are produced by physical dice in a controlled studio environment. This creates a different audit profile than software-based casino games. Rather than certifying a random number generator, testing laboratories such as Gaming Laboratories International certify the physical dice specifications, the shuffle and roll procedures dealers follow, and the computer vision or manual entry systems that capture each outcome.
The audit covers the game state logic as well: whether the platform correctly maps physical dice outcomes to all affected bet types, handles edge cases such as dice leaving the table correctly, and maintains a tamper-evident log of every outcome and corresponding payout calculation. These logs are what operators provide to regulators and to players disputing a result. A live craps platform without a complete, auditable outcome record isn’t just a technical gap — it’s a licensing compliance issue in every US state with operational online gaming regulations.
