Meeting notes from Media-over-QUIC-Web Transport discussion, October 11, 2022
IETF defining WebTransport?. It is a transport protocol (specified by the IETF) and an easy-to-use Web API (specified by the W3C?), that enables clients operating under the Web security model to communicate with a remote server using a secure, multiplexed, real-time transport. WebTransport? provides:
- multiple uni-directional and bi-directional streams of reliable and ordered data.
- an unreliable flow of UDP-like datagrams
- operation over HTTP/3 with fallback to HTTP/2
- Should solve problem of webRTC for RTC, HLS/DASH for higher latency.
W3C? defining Web APi? for WebTransport?. Spec here: https://w3c.github.io/webtransport/
Media over Quic (MoQ?) is IETF group assigned will develop a simple low-latency media delivery solution for ingest and distribution of media. Use cases including live streaming, gaming, and media conferencing and will scale efficiently. Implementable in both browser and non-browser endpoints. The media publication protocol will enable sending media including audio, video, and timed metadata, such as closed captions and cue points. The common protocol for publishing media for ingest and distribution will support:
- one or more media formats,
- an interoperable way to request media and encodings,
- rate adaptation strategies based on changing codec rates, changing chosen media encoding/qualities, or other mechanisms
- cache friendly media mechanisms
Discussion points:
- Set of new APIs? -what should media API look like? Likely a Javascript library to glue together WT, WebCodecs?, MSE.
- How adjust quality, latency knob? WebRTC chooses what to send, drops packets, congestion control.
- Missing in web API - prioritization. This is being debated here: https://github.com/w3c/webtransport/issues/419
- What about server side libraries? Use off-the-shelf QUIC libraries.
- WARP - take GOP, send over network, reassemble. Not deal with packets or congestion control.
- Is complexity there for a reason? Allows you to drop packets for sending.
- Any interest in HLS/DASH? WARP is CMAF compatible. Don’t want to re-encode based on protocol.
- What relation between RUSH/WARP/Moq/WT? WebTransport? is like websockets without HoL? blocking. MoQ? is trying to standardize a protocol for contribution and distribution. WARP and RUSH will be merged, new protocol will be called RUSH. Frame vs GOP is main difference.
- CDN prefers one protocol for distribution. Caching/scaling is the key concern here. WT, no notion of caching. WARP handles caching with unique IDs?, but this may not be most scalable.
- CISCO QUIC-R draft want something that is filter/subscription based. Why wouldn’t this work?
- Network appropriate latency is required. Strict rules for latency don’t allow global distribution. Latency should not be baked into protocol.
- Biggest thing with scale is make it simple, to get CDNs? onboard.
- Routing is the . CISCO cares about routing. Put more logic in client. RTMP does something similar. Want one protocol that does both contribution and distribution. 1:1 versus 1:n should not matter. Subscribe with authentication. With WARP, URL contains token.
- Subscription based push sounds like multicast.
- LL-DASH and LL-HLS both have hoL blocking, so cannot work for RTC.
- What about advertising? SSAI will need to inject ads. Challenge with caching of ads and primary content with CDNs?.
- Is VOD use case valid. Yes. Although HLS/DASH do fine.
- Controls on client? WARP provides simple controls.
- Player should hint to server what latency it wants for live.
- Lucas Pardue made a draft for priority header for QUIC.
- How handle variation in client feature support? Will there be negotiation before start? Start of session could be text file that is exchanged about what is available.
- Timed-metadata goes in own stream, as do captions. Same for SVC layers.
Demos -
Action items for group: