Skip to content

Transport

This document specifies how video data is transported between components.

Overview

Use CaseProtocolDirection
Live streamingWebSocketServer → Proctor (push)
Live streamingWebSocketSentinel → Server (push)
Historical playbackHTTPProctor → Server (pull)
Control messagesWebSocketBidirectional

WebSocket: Live Streaming

All live video data flows over WebSocket connections.

Sentinel → Server

The Sentinel pushes fragments to the Server as they are finalized.

See Terminology for the distinction between fragments (live delivery units) and keyframes (join points).

Server → Proctor

The Server pushes fragments to subscribed Proctors as they arrive.

Data Format

The spec does not mandate a specific serialization format for WebSocket messages. Implementations may use:

  • JSON with base64-encoded binary data
  • Binary WebSocket frames with a header
  • Protocol Buffers
  • Other formats

The key requirement is that the message contains:

FieldTypeDescription
sentinelIdstringIdentifies which Sentinel this fragment belongs to
sequenceintegerFragment sequence number
databytesRaw fMP4 fragment bytes (moof + mdat)

Additional metadata (framerate, timestamp) may be included or derived from the fragment bytes.

Initialization Segment

The initialization segment is sent separately, typically:

FieldTypeDescription
sentinelIdstringIdentifies which Sentinel
databytesRaw fMP4 initialization segment bytes

HTTP: Historical Playback

For accessing fragments that have aged out of the memory buffer, Proctors use HTTP.

Required Information

To fetch a historical fragment, the Proctor needs:

InformationDescription
sentinelIdWhich Sentinel’s stream
sessionIdWhich session
sequenceWhich fragment (or range)

Response

The HTTP response contains the raw fMP4 fragment bytes with appropriate content headers.

HeaderValue
Content-Typevideo/mp4
Content-LengthSize in bytes

Listing Available Fragments

Proctors may need to query which fragments are available for a session. The response should include:

FieldTypeDescription
sentinelIdstringSentinel identifier
sessionIdstringSession identifier
fragmentsarrayList of available fragment metadata

Each entry:

FieldTypeDescription
sequenceintegerFragment number
startTimetimestampWhen the fragment starts
durationintegerDuration in milliseconds
The exact HTTP endpoint structure is implementation-defined. The spec only defines what information must be available.

Protocol Selection

When to Use WebSocket

ScenarioUse WebSocket
Live stream viewingYes
Joining a streamYes (get init + recent fragments)
Control messages (keyframe request, FPS change)Yes
Real-time fragment push from SentinelYes

When to Use HTTP

ScenarioUse HTTP
Fetching fragments older than buffer windowYes
Querying available sessions/fragmentsYes
Downloading for export/archivalYes

Connection Lifecycle

Sentinel Connection

  1. Sentinel establishes WebSocket connection to Server
  2. Sentinel sends registration/identification
  3. Sentinel begins pushing fragments
  4. Connection remains open for session duration
  5. On disconnect, session ends

Proctor Connection

  1. Proctor establishes WebSocket connection to Server
  2. Proctor sends registration/identification
  3. Proctor subscribes to one or more Sentinel streams
  4. Server pushes fragments for subscribed streams
  5. Proctor may switch subscriptions during session
  6. Connection remains open while Proctor is active

Bandwidth Considerations

Since Sentinel and Server are expected to be on the same LAN:

  • Bandwidth is not a primary constraint
  • Single-frame messages are acceptable
  • No need for aggressive batching or compression beyond H.264

For Proctor connections (potentially over WAN):

  • The memory buffer (15-20 seconds) provides catch-up capacity
  • Proctors with slow connections may fall behind
  • If behind by more than buffer window, Proctor must skip forward or use HTTP for historical catch-up
Last updated on • J.H.F.