22 lines
1.1 KiB
Markdown
22 lines
1.1 KiB
Markdown
# ECP-0041: CMAF-Only Chunking (Canonical Container)
|
|
|
|
## Why
|
|
|
|
We want a single canonical chunk container so relays, caches, signatures, and verification can be consistent across sources. Multiple container codepaths (TS chunks, ad-hoc HLS, etc.) make determinism and validation harder, and complicate interop between ingest modules.
|
|
|
|
## Decisions
|
|
|
|
- The canonical chunk container is CMAF (fMP4): `init.mp4` plus numbered `segment_*.m4s`.
|
|
- All ingest pipelines normalize into CMAF segments.
|
|
- Legacy TS chunking is removed from the default pipeline.
|
|
- HLS playlists may still be generated as a local playback compatibility artifact, but the network objects and manifests are CMAF segments.
|
|
- Implementation note: when publishing over a single object track (e.g. local file relay), we reserve chunk index `0` for `init.mp4` and start media segments at index `1` to avoid collisions.
|
|
|
|
## Scope
|
|
|
|
- `ec-node` and the desktop app converge on CMAF output.
|
|
- Existing manifest + object hashing/signing remains, but now hashes refer to CMAF bytes.
|
|
|
|
## Reversibility
|
|
|
|
Medium. Reintroducing TS chunking later is possible behind a feature flag, but the default stays CMAF-only.
|