WEBVTT

00:00:00.000 --> 00:00:03.042
A streaming stack usually starts with a transport choice.

00:00:03.553 --> 00:00:06.571
You pick R T M P, or S R

00:00:06.653 --> 00:00:09.915
T, or Web R T C, and the rest

00:00:09.961 --> 00:00:13.410
of the system grows around that decision. Changing it

00:00:13.456 --> 00:00:16.985
later means changing the system. WAVE makes a different

00:00:17.020 --> 00:00:20.271
bet. The Media Engine is one core with one

00:00:20.341 --> 00:00:22.964
A P I, and every transport is a thin

00:00:23.022 --> 00:00:26.250
adapter over it. The protocol becomes a parameter of

00:00:26.297 --> 00:00:30.163
the call, not the shape of your codebase. The

00:00:30.232 --> 00:00:34.249
set. WAVE speaks the transports that real production already

00:00:34.330 --> 00:00:39.125
uses: - R T M P — the long-standing

00:00:39.218 --> 00:00:42.991
ingest default, still everywhere. - S R T —

00:00:43.340 --> 00:00:46.950
reliable transport over lossy networks, the contribution workhorse. -

00:00:47.113 --> 00:00:50.329
N D I — broadcast-grade video on the L

00:00:50.410 --> 00:00:53.754
A N. - Dahn-tay — low-latency audio over I

00:00:53.847 --> 00:00:56.738
P. - O M T — an open transport

00:00:56.773 --> 00:00:59.652
for media over I P. - Mock — Media

00:00:59.710 --> 00:01:03.449
over Quick, the emerging low-latency standard. - Web R

00:01:03.600 --> 00:01:08.371
T C — sub-second, two-way, browser-native. - H L

00:01:08.487 --> 00:01:12.969
S — scalable one-to-many delivery. Ingest on one, deliver

00:01:13.039 --> 00:01:16.940
on another. The source and destination transports are independent

00:01:17.114 --> 00:01:19.204
— the A P I is the same either

00:01:19.262 --> 00:01:24.103
way. Why a thin adapter matters. Keeping each transport

00:01:24.149 --> 00:01:27.887
thin is a discipline, not an accident. The adapter

00:01:27.957 --> 00:01:32.021
handles the wire format; everything else — auth, entitlement,

00:01:32.148 --> 00:01:36.212
metering, identity — lives once, in the gateway, behind

00:01:36.258 --> 00:01:39.219
the A P I. That means: - A new

00:01:39.277 --> 00:01:42.226
transport is a new adapter, not a new platform.

00:01:43.038 --> 00:01:47.218
- Pricing, payment, and metering are identical across transports.

00:01:47.729 --> 00:01:50.573
- A person and an agent reach every transport

00:01:50.608 --> 00:01:53.615
through the same routes. Bring in over S R

00:01:53.696 --> 00:01:56.854
T, fan out to Web R T C for

00:01:56.889 --> 00:01:59.942
the interactive end and H L S for the

00:01:59.989 --> 00:02:05.341
audience — one call, three transports. The point. The

00:02:05.399 --> 00:02:08.267
hard part of video infrastructure was never any single

00:02:08.301 --> 00:02:11.111
protocol. It was carrying all of them through one

00:02:11.157 --> 00:02:14.315
consistent surface, and pricing and metering them the same

00:02:14.362 --> 00:02:18.936
way. WAVE's answer is the Media Engine: one A

00:02:19.087 --> 00:02:22.442
P I, every transport, each one a thin adapter

00:02:22.651 --> 00:02:25.031
— and the Money Engine settling the bill behind

00:02:25.101 --> 00:02:28.549
it, for people and agents alike. - Transports and

00:02:28.584 --> 00:02:31.719
the A P I: docs dot wave dot online

00:02:31.870 --> 00:02:37.698
- Per-transport adapters: ndi · dante · omt ·

00:02:37.814 --> 00:02:39.892
moq, each at