> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt
> Use this file to discover all available pages before exploring further.

# Media & Transport

> How Reactor streams audio and video from your model to clients.

Reactor handles the entire media pipeline between your model and connected clients. You yield frames
and audio samples from Python. Reactor encodes, packetizes, and delivers them over WebRTC with
adaptive bitrate and low latency.

## Transport

All media is delivered over **WebRTC**. Clients connect via standard SDP offer/answer negotiation,
and frames stream over RTP with sub-50ms delivery latency. The runtime manages the full WebRTC
lifecycle: ICE, DTLS, SRTP, and congestion control.

Commands and messages between the client and model travel over a WebRTC data channel alongside the
media streams.

## Video codecs

Reactor supports multiple video codecs, negotiated automatically with each client via SDP:

| Codec | Notes                                               |
| ----- | --------------------------------------------------- |
| VP9   | Profile 0. Good compression at real-time rates      |
| VP8   | Broad browser compatibility                         |
| H.264 | Constrained Baseline profile. Widest device support |
| AV1   | Best compression. Growing browser support           |
| H.265 | Negotiated when the client offers it                |

The table is the runtime's preference order: it takes the first of these that appears in the
client's offer. VP9 leads for its balance of quality and compression, with H.264 close behind for
maximum device compatibility. Encoding is done in software.

## Audio codec

Audio is encoded with **Opus** at 48 kHz. Opus is the standard WebRTC audio codec and is supported
by all modern browsers.

| Property    | Value               |
| ----------- | ------------------- |
| Codec       | Opus                |
| Sample rate | 48 kHz              |
| Frame size  | 10 ms (480 samples) |

## Resolution

There are no hardcoded resolution limits. The runtime encodes and streams whatever resolution your
model produces. If your model yields 720p frames, the stream is 720p. If it yields 4K, the stream is
4K.

## Bitrate

The runtime uses adaptive bitrate control based on network conditions. It monitors transport-level
feedback and adjusts encoding bitrate dynamically, scaling between 500 kbps and 10 Mbps depending on
available bandwidth.

## Multiple tracks

A model can output any combination of video and audio tracks. Each field on your `Output` class
becomes a separate media track:

```python theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
class MyOutput(Output):
    main_video: Video
    secondary_video: Video
    main_audio: Audio
```

Track names (`main_video`, `secondary_video`, `main_audio`) are the identifiers clients use to
subscribe to specific streams.

## When the model falls behind

Each connection plays out at the rate its chunks are tagged with. When a tick comes round and the
next frame is still being generated, the client holds the frame it already has and the wire stays
quiet, which keeps the bandwidth for real content. A single black frame marks each boundary: the
start of a connection, or a [`flush()`](/deploy/development/reactor-model/run-loop#controlling-playout).
That is what gives a client a clean opening frame.

In the other direction, `emit()` throttles a model that generates faster than the playout rate. See
[Buffered latency](/deploy/development/reactor-model/run-loop#buffered-latency).

## Packet loss recovery

The runtime enables RTP retransmission (RTX) by default. Lost packets are retransmitted from a short
buffer (200 ms), keeping streams clean without adding latency for packets that arrive normally.