49 lines
1.6 KiB
Markdown
49 lines
1.6 KiB
Markdown
# ECP-0053: Direct WebRTC Wire Framing (Chunked Frames)
|
|
|
|
Status: Draft
|
|
|
|
## Problem
|
|
|
|
`direct-publish` currently sends each CMAF object (init or `.m4s` fragment) as a single WebRTC
|
|
data-channel message (`encode_object_frame(meta, data)`).
|
|
|
|
Real OTA CMAF fragments routinely exceed typical data-channel maximum message sizes, causing
|
|
runtime failure like:
|
|
|
|
- `Error: outbound packet larger than maximum message size`
|
|
|
|
This blocks real-world HDHomeRun end-to-end streaming via `https://every.channel`.
|
|
|
|
## Goal
|
|
|
|
Make direct WebRTC transport robust by supporting large objects while keeping:
|
|
|
|
- ordered delivery,
|
|
- simple decoding in the website and CLI,
|
|
- no additional servers beyond the existing bootstrap API.
|
|
|
|
## Proposal
|
|
|
|
Define a minimal application-layer framing over WebRTC data-channel messages:
|
|
|
|
- Each data-channel message begins with a 1-byte tag:
|
|
- `0x00`: legacy "whole object frame in one message" (optional compatibility)
|
|
- `0x01`: stream-chunk bytes (new default)
|
|
- In `0x01` mode, bytes carry a length-prefixed stream:
|
|
- `[u32_be length][frame bytes]` repeated
|
|
- `frame bytes` are exactly the existing `encode_object_frame(meta, data)` output
|
|
- Publishers MUST:
|
|
- use `0x01` mode,
|
|
- split the stream into safe message payloads (e.g. 16 KiB chunks)
|
|
- Subscribers SHOULD:
|
|
- accept both `0x01` and `0x00` to ease rollout.
|
|
|
|
## Rollout
|
|
|
|
- Update `ec-node direct-publish`, the website receiver, and `ec-node direct-subscribe`.
|
|
- Redeploy static site assets; bootstrap API unchanged.
|
|
|
|
## Reversibility
|
|
|
|
- The change is localized to `direct-*` and can be removed or replaced without touching MoQ.
|
|
|