Prerequisites: level 101 and the relay overview in level 102. Outcome: follow one frame through the system and select evidence for a streaming failure. Allow: 30 minutes. This is a worked design exercise, not a live benchmark.

​
The example application

A camera publishes a 2 Mbps video stream to a relay. Ten viewers subscribe to it. Assume the relay forwards the same encoded media to every viewer without transcoding. The target glass-to-glass delay is 100 ms. All numbers in this walkthrough are teaching assumptions.

​
Step 1: produce media that can be decoded

The encoder transforms captured images into compressed media. A keyframe can provide a decoding starting point without earlier video frames, subject to the codec’s configuration requirements. Other frames can depend on previous frames. A new viewer needs the applicable codec configuration and a usable starting point. Receiving arbitrary bytes from the middle of a dependency chain does not guarantee a visible picture. Media packaging determines how codec data maps to MoQ objects and groups. Do not assume that every object is an independently decodable image.

​
Step 2: publish objects through the relay

The publisher opens its session and publishes the appropriate track. The relay uses the track and object metadata to route the data. The subscriber uses the matching track name and namespace. The publisher sends one copy of the media to this relay in the simplified example. Its media upload rate is approximately 2 Mbps. The relay’s media egress for ten viewers is approximately 10 * 2 = 20 Mbps. Protocol overhead, retransmissions, and other traffic add to both figures. For 1,000 viewers at the same rate, the relay tier needs approximately 2,000 Mbps of media egress. Fan-out moves the multiplication away from the camera; it does not remove the work.

​
Step 3: let a viewer join

  1. The viewer resolves the endpoint and opens its transport session.
  2. The application establishes identity and requests the permitted track.
  3. The relay accepts the request or returns a failure.
  4. The viewer receives the configuration and media needed to start decoding.
  5. The viewer buffers, decodes, and displays the media.
Steps can overlap depending on the implementation. This list describes application responsibilities, not a fixed count of protocol messages. The SDK reference defines the methods for the selected version.

​
Step 4: account for delay

Use the budget from the foundation lesson: If the viewer buffer grows to 70 ms, the total becomes 135 ms. The first question is why the buffer grew. Possible causes include varying arrival times, slow decoding, or a policy that retains old frames. Measure the relevant stage before changing the transport.

​
Step 5: diagnose one symptom at a time

These are hypotheses, not diagnoses. For example, a blank picture with arriving objects does not prove that the relay is healthy in every respect. It narrows the next check to the content and processing of those objects.

​
Exercise

  1. Calculate media egress for 25 viewers at 2 Mbps each.
  2. A subscriber receives objects but displays no video. Name two checks before changing the subnet configuration.
  3. The viewer buffer adds 45 ms. How much must other stages improve to retain the 100 ms target?
  4. Explain why dropping an arbitrary video object can affect later objects.
  1. The assumed media egress is 50 Mbps, before overhead and retransmissions.
  2. Check codec configuration and whether the received sequence contains a usable decoding starting point. Read the decoder’s errors.
  3. The original total was 90 ms. The new total is 135 ms, so at least 35 ms must be removed.
  4. Later frames can depend on the dropped data. A deliberate dependency-aware discard policy differs from discarding arbitrary bytes.
Completion check: draw this pipeline and identify the measurement that would distinguish a relay queue from a viewer buffer. Next: level 102 worked answers, then build a publisher and subscriber.