A streaming stack usually starts with a transport choice.
You pick R T M P, or S R
T, or Web R T C, and the rest
of the system grows around that decision. Changing it
later means changing the system. WAVE makes a different
bet. The Media Engine is one core with one
A P I, and every transport is a thin
adapter over it. The protocol becomes a parameter of
the call, not the shape of your codebase. The
set. WAVE speaks the transports that real production already
uses: - R T M P — the long-standing
ingest default, still everywhere. - S R T —
reliable transport over lossy networks, the contribution workhorse. -
N D I — broadcast-grade video on the L
A N. - Dahn-tay — low-latency audio over I
P. - O M T — an open transport
for media over I P. - Mock — Media
over Quick, the emerging low-latency standard. - Web R
T C — sub-second, two-way, browser-native. - H L
S — scalable one-to-many delivery. Ingest on one, deliver
on another. The source and destination transports are independent
— the A P I is the same either
way. Why a thin adapter matters. Keeping each transport
thin is a discipline, not an accident. The adapter
handles the wire format; everything else — auth, entitlement,
metering, identity — lives once, in the gateway, behind
the A P I. That means: - A new
transport is a new adapter, not a new platform.
- Pricing, payment, and metering are identical across transports.
- A person and an agent reach every transport
through the same routes. Bring in over S R
T, fan out to Web R T C for
the interactive end and H L S for the
audience — one call, three transports. The point. The
hard part of video infrastructure was never any single
protocol. It was carrying all of them through one
consistent surface, and pricing and metering them the same
way. WAVE's answer is the Media Engine: one A
P I, every transport, each one a thin adapter
— and the Money Engine settling the bill behind
it, for people and agents alike. - Transports and
the A P I: docs dot wave dot online
- Per-transport adapters: ndi · dante · omt ·
moq, each at