24 lines
1.3 KiB
Markdown
24 lines
1.3 KiB
Markdown
# ECP-0042: Multi-Variant Publishing and Automatic Selection
|
|
|
|
## Why
|
|
|
|
Different networks and devices need different bitrates/resolutions. A single stream quality forces either wasted bandwidth or playback stalls. We also need a consistent representation of variants so multiple peers can publish/verify the same logical channel.
|
|
|
|
## Decisions
|
|
|
|
- A "channel" may have multiple *variants* (e.g. `1080p`, `720p`, `480p`) produced from the same timing grid.
|
|
- Manifests include per-variant metadata (resolution/bitrate) and per-variant chunk hashes for the same chunk index.
|
|
- Viewers implement automatic selection:
|
|
- Prefer the highest variant that keeps steady playback.
|
|
- Step down quickly on sustained stalls; step up conservatively.
|
|
- Where available, the desktop app may present variants via a master playlist so the platform player can do ABR; protocol objects remain per-variant CMAF.
|
|
- Initial implementation may subscribe to all variants concurrently and let the player switch locally. More efficient "switch by resubscribe" can come later.
|
|
|
|
## Non-Goals (for this ECP)
|
|
|
|
- Global policy/quotas/anti-junk (separate proposal).
|
|
- Hardware encode determinism guarantees (separate proposal).
|
|
|
|
## Reversibility
|
|
|
|
High. Variant publishing and selection policies can evolve without breaking base single-variant streams.
|