Re: [media-and-entertainment] Interest in WebTransport + WebCodecs? (#25)

I note that WebCodecs is now being tracked in a separate issue #40.

The WebTransport Working Group was created earlier this year as proposed. The group published a First Public Working Draft of the specification early May:

The specification has made a lot of progress since last discussions on the topic in the Media & Entertainment IG, notably in terms of effective transport semantics. As part of TPAC 2021 plans (#71), it could be worth considering a joint call with the WebTransport Working Group to review progress and assess whether WebTransport can be a useful brick from a media streaming perspective.

On top of my head, some considerations/questions that could perhaps be useful to discuss:

- **Scalability**: Main envisioned use case for WebTransport in media contexts is for low-latency streaming. Can WebTransport leverage CDN/caching infrastructures in low-latency scenarios? Also, to benefit from caching, would the resulting latency be similar to that in low-latency DASH and HLS? In other words, what added value could WebTransport bring in that space? (for instance, would the ability to create "unreliable" transport be a major boost?)
- **Integration with MSE**: One envisioned path for realtime scenarios is WebTransport + WebCodecs. But media companies are used to rendering media content with MSE+EME. Would WebTransport + MSE work as well? How simple is it to plug WebTransport and MSE?
- **Benefits over HTTP/3**: WebTransport builds on top of HTTP/3. When HTTP/3 becomes widely available, what would be the added value of using the WebTransport API rather than fetching content over HTTP as currently done in adaptive streaming solutions?

What about it? Are there other points to discuss?

GitHub Notification of comment by tidoust
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 23 June 2021 09:32:55 UTC