Meeting minutes
Introduction
ChrisN: A few topics
today.
… Web Transport updates, Media WG
updates
… then TPAC planning
… anything else?
(none)
Web Transport
Will: Web Transport is
about real-time data. Looking at applications, what might we want
to build?
… Real time audio and video, improved
privacy
… Game engines, important to transfer information
quickly
… Cloud game rendering and deliver to the
client
… Sports and news in OTT
… Also industrial and security cameras
… IoT sensor data, vehicle data reporting, pub-sub
data
… Real time speech translation, audio going in and
transcribed words coming out
… Common requirements across the use cases. Modern
web security, client/server architecture
… WebRTC not always using peer to peer. Client
server allows optimisation
… Data one way, control message in the
other
… Reliable data, also datagrams which trade
reliability for latency
… Backpressure, to manage data flow
… Something with URIs. No candidate across all
these. Protocol options?
… REST APIs, HTTP about file object retrieval.
Lossless, but not optimal for fast delivery
… WebSockets is good for real time dlivery, but
suffers from head-of-line blocking
… WebRTC is a stack of many protocols, solves some
of the head-of-line blocking issues, but it's built on
peer-to-peer
… A lot of work involved in NAT traversal, so it's
not efficient for a client and server
… Can roll your own UDP, but the burden is on you
to install your SDK
… Traditional DASH or HLS segmented media. Not fast
enough, even in chunked encoded mode
… Unbundling. WebRTC is closest to what we need.
We'd like to specialise ... like buying a car, it works according
to a package
… If I can decompose it into its components, I can
specialise my vehicle ... a sports car or a bus, etc
… Apply the analogy to WebRTC. It has a lot of
additional functions. How to unbundle?
… For codecs we have WebCodecs, for compute there's
WASM
… Secure streams needs a real time data transport
for the web
… WebTransport fills that gap
… It intends to solve real time data transfer for
the web. IETF protocol and Web API
… Secure multiplexed transport. Reliable data,
unreliable UDP-like datagrams. They're encrypted and subject to
congestion control
… It operates over HTTP/3 and also HTTP/2. Your app
won't fail under H2, but it won't be as quick
… WebTransport is built on the IP/UDP stack, builds
on QUIC. This is all done at IETF
… Transfer modes are interesting. Consider
WebTransport as a pipe, send objects down a stream
… They come out in the same order as I sent
them
… I can send datagrams, speed is more important
than reliability
… I can have multiple streams with WebTransport.
Within a stream the order is preserved, but not between
streams
… It solves the head-of-line blocking problem. If
one stream is blocked, I can continue to send others. It's known as
partial reliability, but I don't like the term: it's reliable
within a stream
… The API has a public working draft
… It's in secure contexts only
… It uses modern web platform primitives, using
Promises and Streams
… Familiar URI construct: HTTPS with port. It can
run in a Worker for multi-threading
… Can do powerful things in a few lines of
JavaScript
… [Slides 11/12]
… Send and receive and process. Create a
unidirectional stream and a writeable. The stream sends continues
to send data after it's closed
… Scenario: processing one stream at a time. Listen
to incoming stream and pipe to a text decoder, pipe those into
another object to display the text
… The API is clean for piping between
processors
… Can try it for yourself. There's an AIOQuic
library, that we'll use for Web Platform Tests. Chrome has an
Origin Trial since M84
… What doesn't WebTransport do? It doesn't support
peer to peer. WebRTC is good for that
… It doesn't give a built-in messaging framework,
whereas WebSocket does. That's by design, it's a low level tool
usable in many apps
… No framing for video payloads
… WebTransport gives you the pipe. Libraries would
be responsible for that
… What's exciting about it? Unify the transport and
API between telephony, gaming, low latency and live media
delivery
… Common transport and common API. Like it from CDN
point of view
… It'll look like HTTP/3 from a firewall point of
view. With browser support it'll have billions of
devices
… Datagram access in JavaScript
… Close gap between native apps and
browser
… Chrome will ship by November this year. Firefox
working on it, no date announced
… We encourage experimentation and feedback. Now is
the time when feedback can be incorporated
… Planning an interop event between IETF and
W3C
… Good overlap with MEIG userbase and the community
we want to reach for Web Transport
… I'll give a live demo
… [Demo shows Chrome with an echo
server]
Kaz: Thank you, Will.
From a WoT point of view, I'm interested in this update and would
like joint discussion from IoT perspective
… Possible use cases could be discussed
Igarashi: You mentioned that the WebTransport spec doesn't include video framing. Would WebCodecs define framing, for a combination of WebTransport and WebCodecs?
Will: We're about to
publish a demo. So you can't pipe the output from WebCodecs into
WebTransport
… The same people are working on both. Example of a
webcam stream from WebCodecs into WebTransport
Piers: How does the signalling of audio and video work? Is it SDP based, or is that not included?
Will: It's client/server, so it's just a pipe. You'd need application logic to handle the data correctly
Piers: I wondered about WebRTC signalling
Will: There'll be whole other layers added for A/V workflows
Piers: Timing
information for data arrival? Is it using the Streams API to
provide data to the app level, on the receive side? How to measure
throughput?
… There's a getStats function that returns how much
data received. You could also count the received data
… A connection can be shared between applications.
Stats could leak information through stats in terms of pooled
connections. There'll be a dedicated H3 connection for
WebTransport, from a privacy point of view
Piers: Detecting of chunk boundaries is a bit tricky
Will: I'd need to get
better information for you. Compared to MSE with fetching chunks it
should be smoother
… Converting low latency DASH to
WebTransport
… Raise an issue for your use case
Nigel: As a follow on
regarding SDP, what's the upgrade or downgrade path from RTP.
There's a layer on top of UDP
… If you have something built on RTP, how do the
parts fit together?
Will: Even though
they're both UDP, it's on top of QUIC
… Someone would need to build an interface where it
looks like you put in RTP and get out the other end, but then it's
put into WT datagrams
… It won't give portability to RTP
<Zakim> nigel, you wanted to ask about the layering on UDP and whether RTP would be replicated or ...
Will: Sam Hurst has put in an IETF draft of RTP over QUIC, and another from Yurgot
Nigel: Want to avoid rebuilding everything that's done over RTP, can we short-circuit that?
Will: There was a BoF
session at the last IETF. I'd encourage people not to do RTP over
QUIC but RTP over WebTransport instead
… Then it becomes more usable from web
applications
Song: I saw the presentation in October to the Chinese live video community. WebRTC sessions are client initiated. WebTransport intends to unify for communications, so can the call be initiated from the other end?
Will: The connection is initiated by the client? It leverages HTTP transport which is client to server. Once the WT connection is established, you have bidirectional communication, but the initial connection is client initiated
<Piers> Here's a
summary of RTP/QUIC drafts and related: https://
Will: If the client is
behind a NAT, the server can't reach it
… After connection, there's symmetry in moving the
data
Song: About remote media production. Is an accurate time synchronisation, e.g., combined with SMPTE2110, is there an advantage for WebTransport for web based remote media production platforms?
Will: Certainly. If you
look at remote production apps, they're client/server. You don't
need peer to peer. I'd worry about bandwidth differences between
SMPTE2110 and what you'd expect over the internet
… It's a good use case, we could add it
Francois: For regular media streaming, is WT not a good fit, or could it be useful if you build the right libraries?
Will: At Akamai, we
care about live distribution. VoD is a poor-fitting use case. WT is
not cacheable with existing caching servers
… We have a good system for that today, not much
benefit moving. LL DASH and HLS has large efficient distribution
infrastructure, 1-2 second latency
… Low latency live sports gets interesting, e.g.,
400ms latency is the crossover point. If I can use intfrastructure
for telephony etc, get a stream out to a million
people
… Need to solve DRM, high dynamic range,
transformation at the last mile
… The square peg in the round hole is latency in
the several second range
ChrisN: Any specific questions we can help with in the WG?
Will: We're currently
thinking about error codes. Also what stats people need? Fallback
to HTTP/2 - is it also worth doing fallback to HTTP/1?
… Questions about how to move media, and we need
more clarity over it. That's still early. When we have functioning
servers and clients we can move to the next layer, see how to do
that efficiently
Media WG updates
ChrisN: Media WG ran a
CfC for WebCodecs, whether to expose in Window or Worker-only
… Data from experiments and user feedback. On
balance we thought Window exposure was fine, developers can choose
depending on their needs.
… Chrome 94 will ship the API publicly.
ChrisN: How to do media
packaging and stream via Web Transport is interesting.
… Developer feedback is very welcome.
… Next, MSE v2. We sent a CfC for publishing
FPWD.
… This will include two of the main features
planned in MSE v2,
… enabling codec switching and MSE in dedicated
workers.
… Use in a Worker should make streaming apps more
responsive to user inputs.
… Next WG meeting will be next week, Sep
14.
… Netflix raised some interoperability issues for
MSE ISO-BMFF Bytestream, recommend reviewing
TPAC planning
ChrisN: really would like your input
ChrisL: Comcast is
interested in UI
… Struggling with performance
… What are the bottlenecks?
ChrisN: Thanks.
… We'll find dates for discussion.
… joint meetings with related groups
… We had discussion with C2PA, and asking them to
have discussion again
… also Multicast CG
… The other thing we historically do during TPAC is
Industry updates
… CTA WAVE about latest updates
… HbbTV, IPTV Forum Japan, ATSC as well
Will: Would like to
follow up
… with Multicast CG as well
ChrisN: Multi-forum discussion would be nice
<JohnRiv> multi-forum discussion that includes CTA WAVE sounds good to me too
kaz: Given the meeting wiki needs to be updated by the end of this week, we should make decision on the date by the end of this week
ChrisN: Yes, let's have further discussion offline
Upcoming workshops
ChrisN: Some more
updates: Two workshops are coming up.
… Workshop on wide color gamut and HDR is
September.
… Also professional media production in November,
we're looking for presenters.
… Our next meeting will be held on Oct 5, input and
suggestions welcome.
[adjourned]