---

1. The core idea

SRT is best understood as:

SPTS (Single Program Transport Stream behavior) carried over a connection-oriented UDP session layer with MTPS-like multiplexing semantics via sessions.

That sounds dense, but it reduces to something very simple:

One stream per session (SPTS-like)
+
Many sessions per socket/port (MTPS-like)
=
SRT

---

2. SPTS vs MTPS vs SRT

SPTS (Single Program Transport Stream)

Classic MPEG world:

1 encoder → 1 stream → 1 destination

Characteristics:

• one linear stream
• no multiplexing at transport level
• point-to-point thinking
• often RTP/UDP

Mental model:

[Encoder] ─────► [Receiver]

---

MTPS (Multi Program Transport Stream)

Broadcast mindset:

1 transport → many programs/services

Characteristics:

• multiplex multiple programs in one stream
• typically DVB-style thinking
• shared carriage
• multiple logical services

Mental model:

          ┌─ Program A
[Transport]├─ Program B
          └─ Program C

---

SRT (what it actually behaves like)

SRT splits the difference in a very pragmatic way:

Transport level

• Each SRT connection behaves like SPTS
• One stream per session

Network level

• A single listener port can serve many concurrent sessions
• This gives MTPS-like multiplexing at the socket boundary

So:

          (single port)
               │
     ┌─────────┼─────────┐
     ▼         ▼         ▼
 Session 1  Session 2  Session 3
 (SPTS)     (SPTS)     (SPTS)

That’s the key observation to make:

SRT is SPTS per session, MTPS per listener socket.

---

3. Why “single port” matters

Traditional streaming stacks:

RTMP: one port, many streams, messy multiplexing semantics

RTP: many ports, session management complexity

SRT: one port, many sessions, clean abstraction

SRT’s listener behaves like:

bind(udp://0.0.0.0:9000)

→ accepts infinite logical streams
→ each identified by handshake/session

So a control plane doesn’t need port gymnastics.

---

4. The session is the real primitive

In SRT, the session is everything.

A session contains:

• stream identity
• sequence space
• congestion control state
• ARQ (retransmission state)
• RTT estimation
• latency buffer
• encryption keys (if enabled)

So instead of:

IP:port = stream identity

you get:

session = stream identity

That’s a major architectural shift.

---

5. Bidirectionality (why SRT feels “alive”)

SRT is not just “send UDP packets and hope”.

Every session is inherently bi-directional control-plane + uni-directional media-plane:

Media flow

A → B (MPEG-TS)

Control flow (embedded in same session)

B → A:
- ACKs
- NAKs
- bandwidth signals
- RTT updates

So every stream is constantly self-correcting.

This is why it feels stable even on messy networks.

---

6. Wavehand

A log:

result: waveahand

This is SRT’s handshake phase.

Think of it as:

1. UDP packets start flowing
2. peers negotiate session parameters
3. encryption keys exchanged (if enabled)
4. sequence spaces aligned
5. latency buffers agreed
6. session becomes “live”

After Wavehand:

“this UDP flow is now a managed media session”

---

7. Why SRT feels like “modern RTP done right”

RTP:

• stateless transport
• external RTCP side channel
• app must glue everything together

SRT:

• built-in session state
• built-in retransmission (ARQ)
• built-in congestion control
• built-in handshake
• single-port multiplexing

So SRT collapses a lot of infra into the protocol itself.

---

8. Latency model

This is the key abstraction:

latency = repair window

Not “delay”.

More precisely:

Latency buffer =
time allowed for:
  - packet loss detection
  - NAK propagation
  - retransmission arrival
  - reordering

---

In a local media fabric

You get:

Network characteristics

RTT: 0.2–2 ms
loss: ~0
jitter: tiny

So:

Latency budget can shrink dramatically

Typical internet SRT:

120–300 ms

Local fabric SRT:

5–20 ms

Same reliability, way less buffering.

---

9. What actually happens when latency is too low

If you go too aggressive:

latency = 2ms

Then:

• packet arrives late by 3–10ms
• it misses the buffer window
• SRT cannot recover it
• you get visible corruption

So the tradeoff becomes:

lower latency
→ smaller repair window
→ higher risk of visible loss

---

10. Why SRT is perfect for media system internal fabric

A system has:

Ingest nodes
→ control plane
→ MPEG-TS routing
→ workers
→ outputs

SRT gives you:

1. Session-based stream identity (SPTS model)

• each feed is cleanly isolated

2. Single-port fan-in (MTPS-like convenience)

• ingest scale without port management

3. Reliable UDP semantics

• no TCP head-of-line blocking

4. Built-in control feedback loop

• congestion + loss handled per stream

So the fabric becomes:

SRT session = atomic media pipe

---

11. Mental model to keep stable

If everything else is forgotten, this is the core abstraction:

SRT = a stateful UDP session that carries exactly one live media stream,
with built-in recovery and timing control.

And:

A listener port = a multiplexing hub for many such sessions.

---

If you internalize just one thing for media system architecture design, it’s this:

You are not routing packets — you are managing sessions with timing budgets.