1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
//! # moq-lite: Media over QUIC Transport
//!
//! `moq-lite` is designed for real-time live media delivery with sub-second latency at massive scale.
//! This is a simplified subset of the *official* Media over QUIC (MoQ) transport, focusing on the practical features.
//! ## API
//! The API is built around Producer/Consumer pairs, with the hierarchy:
//! - [Origin]: A collection of [Broadcast]s, produced by one or more [Session]s.
//! - [Broadcast]: A collection of [Track]s, produced by a single publisher.
//! - [Track]: A collection of [Group]s, delivered out-of-order until expired.
//! - [Group]: A collection of [Frame]s, delivered in order until cancelled.
//! - [Frame]: Chunks of data with an upfront size.
//!
//! ## Compatibility
//! `moq-lite` purposely implements a subset of the IETF `moq-transport` specification.
//! Many features are unsupported on purpose to keep the API and implementation clean,
//! rather than pollute them with half-baked features.
//!
//! That said, the library is forwards-compatible with the full specification and
//! supports moq-transport drafts 14+ via version negotiation. Everything will work
//! perfectly, so long as your application uses the API as defined above.
//!
//! For example, there's no concept of "sub-group" in `moq-lite`. When connecting to
//! a moq-transport implementation, we use `sub-group=0` for all frames and silently
//! drop any received frames not in `sub-group=0`. If your application genuinely needs
//! multiple sub-groups, tell me *why* and we can figure something out.
//!
//! ## Producers and Consumers
//! Each level of the hierarchy is split into a Producer / Consumer pair:
//! - The **Producer** is the writer: it appends new state (publishes a broadcast,
//! starts a group, writes frames, closes a track).
//! - The **Consumer** is a reader: each consumer holds its own independent view
//! of the producer's state, with its own cursor through the stream.
//!
//! Both halves are cheaply clonable so you can hand out multiple handles. Cloning
//! a consumer creates another reader (each at its own cursor); cloning a producer
//! gives another writer that contributes to the same shared state. Closing the
//! last producer signals consumers that no more updates are coming.
//!
//! ## Async
//! This library is async-first, using [tokio] for async I/O and task management.
//! Any plain `async` method should be awaited from inside an active tokio runtime.
//! Otherwise you risk a panic.
//!
//! This requirement is being phased out as more methods grow `poll_xxx` counterparts
//! built on [`conducer`], so you can drive them from custom executors without a tokio
//! runtime. You can also call them synchronously, since [`conducer`] is built on the
//! standard [`std::task::Waker`] API and any [`std::task::Waker`] is a valid driver.
pub use *;
pub use ;
pub use *;
pub use *;
pub use *;
pub use *;
pub use *;
pub use *;
// Re-export the bytes crate
pub use bytes;