13:57:20 RRSAgent has joined #me 13:57:20 logging to https://www.w3.org/2021/09/07-me-irc 13:57:24 Zakim has joined #me 13:57:57 Meeting: MEIG Monthly Meeting 13:58:28 Present: Will_Law, Kazuhiro_Hoya, Chris_Needham, Takio_Yamaoka 13:58:53 Present+ Song_Xu 13:59:46 Chris_L has joined #me 13:59:48 tidoust has joined #me 14:00:02 Present+ Tatsuya_Igarashi 14:00:28 present+ Francois_Daoust 14:00:31 igarashi has joined #me 14:00:59 present+ Chris_Lorenzo 14:01:01 present+ 14:01:18 Present+ Kazuyuki_Ashimura 14:01:59 Present+ Andreas_Tai 14:02:04 scribenick: cpn 14:02:28 kazho has joined #me 14:02:37 atai has joined #me 14:02:40 rrsagent, make log public 14:02:44 rrsagent, draft minutes 14:02:44 I have made the request to generate https://www.w3.org/2021/09/07-me-minutes.html kaz 14:03:10 Present+ Piers_O'Hanlon 14:03:25 chair: ChrisN, ChrisL, Igarashi 14:03:27 rrsagent, draft minutes 14:03:27 I have made the request to generate https://www.w3.org/2021/09/07-me-minutes.html kaz 14:03:43 present- igarashi 14:04:44 https://docs.google.com/presentation/d/1KfhAl7wbk5diRZbMS_vF-yv0_zs6rw3OArKpafl9qHE/edit 14:04:57 s/https/-> https/ 14:05:03 s/edit/edit Slides/ 14:05:13 cpn: a few topics today 14:05:27 Piers has joined #me 14:05:38 ... Web Transport updates, Media WG updates 14:05:50 ... then TPAC planning 14:06:03 ... anything else? 14:06:13 (none) 14:06:24 i/a few/topic: Agenda 14:06:43 i/a few/scribenick: kaz/ 14:07:13 scribenick: cpn 14:07:37 Will: Web Transport is about real-time data. Looking at applications, what might we want to build? 14:07:48 ... Real time audio and video, improved privacy 14:08:01 ... Game engines, important to transfer information quickly 14:08:10 ... Cloud game rendering and deliver to the client 14:08:13 ... Sports and news in OTT 14:08:22 ... Also industrial and security cameras 14:08:37 ... IoT sensor data, vehicle data reporting, pub-sub data 14:08:55 ... Real time speech translation, audio going in and transcribed words coming out 14:09:18 ... Common requirements across the use cases. Modern web security, client/server architecture 14:09:36 ... WebRTC not always using peer to peer. Client server allows optimisation 14:09:44 ... Data one way, control message in the other 14:09:58 ... Reliable data, also datagrams which trade reliability for latency 14:10:07 ... Backpressure, to manage data flow 14:10:25 ... Something with URIs. No candidate across all these. Protocol options? 14:10:44 ... REST APIs, HTTP about file object retrieval. Lossless, but not optimal for fast delivery 14:11:03 ... WebSockets is good for real time dlivery, but suffers from head-of-line blocking 14:11:22 ... WebRTC is a stack of many protocols, solves some of the HoL blocking issues, but it's built on peer-to-peer 14:11:42 ... A lot of work involved in NAT traversal, so it's not efficient for a client and server 14:11:58 ... Can roll your own UDP, but the burden is on you to install your SDK 14:12:28 ... Traditional DASH or HLS segmented media. Not fast enough, even in chunked encoded mode 14:12:51 ... Unbundling. WebRTC is closest to what we need. We'd like to specialise ... like buying a car, it works according to a package 14:12:56 Present+ Nigel_Megitt 14:13:09 ... If I can decompose it into its components, I can specialise my vehicle ... a sports are or a bus, etc 14:13:31 ... Apply the analogy to WebRTC. It has a lot of additional functions. How to unbundle? 14:13:43 ... For codecs we have WebCodecs, for compute there's WASM 14:13:56 ... Secure streams needs a real time data transport for the web 14:14:03 ... WebTransport fills that gap 14:14:27 ... It intends to solve real time data transfer for the web. IETF protocol and Web API 14:14:57 ... Secure multiplexed transport. Reliable data, unreliable UDP-like datagrams. They're encrypted and subject to congestion control 14:15:21 ... It operates over HTTP/3 and also HTTP/2. Your app won't fail under H2, but it won't be as quick 14:15:56 ... WebTransport is built on the IP/UDP stack, builds on QUIC. This is all done at IETF 14:16:19 ... Transfer modes are interesting. Consider WebTransport as a pipe, send objects down a stream 14:16:28 ... They come out in the same order as I sent them 14:16:52 ... I can send datagrams, speed is more important than reliability 14:17:15 ... I can have multiple streams with WebTransport. Within a stream the order is preserved, but not between streams 14:17:48 ... It solves the HoL 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 14:17:54 ... The API has a public working draft 14:18:02 ... It's in secure contexts only 14:18:19 ... It uses modern web platform primitives, using Promises and Streams 14:18:35 ... Familiar URI construct: HTTPS with port. It can run in a Worker for multi-threading 14:18:56 ... Can do powerful things in a few lines of JavaScript 14:19:11 ... [Slides 11/12] 14:20:01 ... Send and receive and process. Create a unidirectional stream and a writeable. The stream sends continues to send data after it's closed 14:20:44 ... 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 14:20:51 ... The API is clean for piping between processors 14:21:23 ... 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 14:21:31 s/sports are/sports car/ 14:21:54 ... What doesn't WebTransport do? It doesn't support peer to peer. WebRTC is good for that 14:22:27 ... 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 14:22:33 ... No framing for video payloads 14:22:55 ... WebTransport gives you the pipe. Libraries would be responsible for that 14:23:29 ... What's exciting about it? Unify the transport and API between telephony, gaming, low latency and live media delivery 14:23:42 .... Common transport and common API. Like it from CDN point of view 14:24:12 ... It'll look like HTTP/3 from a firewall point of view. With browser support it'll have billions of devices 14:24:21 ... Datagram access in JavaScript 14:24:37 ... Close gap between native apps and browser 14:24:52 ... Chrome will ship by November this year. Firefox working on it, no date announced 14:25:07 ... We encourage experimentation and feedback. Now is the time when feedback can be incorporated 14:25:16 ... Planning an interop event between IETF and W3C 14:25:34 ... Good overlap with MEIG userbase and the community we want to reach for Web Transport 14:25:42 ... I'll give a live demo 14:26:39 ... [Demo shows Chrome with an echo server] 14:26:41 q? 14:26:50 q+ 14:26:57 q+ 14:27:29 Kaz: Thank you, Will. From a WoT point of view, I'm interested in this update and would like joint discussion from IoT perspective 14:27:38 ... Possible use cases could be discussed 14:27:47 ack k 14:27:52 ack i 14:28:29 Igarashi: You mentioned that the WebTransport spec doesn't include video framing. Would WebCodecs define framing, for a combination of WebTransport and WebCodecs? 14:29:03 Will: We're about to publish a demo. So you can't pipe the output from WebCodecs into WebTransport 14:29:38 ... The same people are working on both. Example of a webcam stream from WebCodecs into WebTransport 14:29:45 q? 14:30:08 Piers: How does the signalling of audio and video work? Is it SDP based, or is that not included? 14:30:34 rrsagent, draft minutes 14:30:34 I have made the request to generate https://www.w3.org/2021/09/07-me-minutes.html kaz 14:30:35 Will: It's client/server, so it's just a pipe. You'd need application logic to handle the data correctly 14:30:46 Piers: I wondered about WebRTC signalling 14:31:13 Will: There'll be whole other layers added for A/V workflows 14:31:37 q+ to ask about the layering on UDP and whether RTP would be replicated or ... 14:31:38 present+ David_Chiu 14:31:42 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? 14:32:19 ... There's a getStats function that returns how much data received. You could also count the received data 14:33:13 ... 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 14:33:45 Piers: Detecting of chunk boundaries is a bit tricky 14:34:11 Will: I'd need to get better information for you. Compared to MSE with fetching chunks it should be smoother 14:34:30 ... Converting low latency DASH to WebTransport 14:34:47 q+ Song 14:35:09 ... Raise an issue for your use case 14:35:25 JohnRiv has joined #me 14:35:39 Nigel: As a follow on regarding SDP, what's the upgrade or downgrade path from RTP. There's a layer on top of UDP 14:35:59 ... If you have something built on RTP, how do the parts fit together? 14:36:14 Will: Even though they're both UDP, it's on top of QUIC 14:36:43 ... 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 14:36:51 ... It won't give portability to RTP 14:37:05 q? 14:37:09 ack n 14:37:09 nigel, you wanted to ask about the layering on UDP and whether RTP would be replicated or ... 14:37:09 ack ni 14:37:16 ... Sam Hurst has put in an IETF draft of RTP over QUIC, and another from Yurgot 14:37:40 Nigel: Want to avoid rebuilding everything that's done over RTP, can we short-circuit that 14:38:09 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 14:38:19 ... Then it becomes more usable from web applications 14:38:32 ack song 14:39:39 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? 14:40:11 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 14:40:13 Here's a summary of RTP/QUIC drafts and related: https://fiestajetsam.github.io/2021/08/22/quic-video.html 14:40:20 ... If the client is behind a NAT, the server can't reach it 14:40:51 ... After connection, there's symmetry in moving the data 14:41:33 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? 14:42:13 rrsagent, draft minutes 14:42:13 I have made the request to generate https://www.w3.org/2021/09/07-me-minutes.html kaz 14:42:14 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 14:42:31 ... It's a good use case, we could add it 14:42:34 q+ 14:42:36 q? 14:42:49 ack t 14:43:27 Francois: For regular media streaming, is WT not a good fit, or could it be useful if you build the right libraries? 14:43:55 Will: At Akamai, we care about live distribution. VoD is a poor-fitting use case. WT is not cacheable with existing caching servers 14:44:27 ... 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 14:45:11 ... 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 14:45:29 ... Need to solve DRM, high dynamic range, transformation at the last mile 14:45:46 ... The square peg in the round hole is latency in the several second range 14:45:48 q? 14:46:44 Chris: Any specific questions we can help with in the WG? 14:47:21 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? 14:48:09 ... 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 14:49:05 scribenick: kaz 14:49:35 topic: Media WG updates 14:49:54 cpn: ran a cfc for WebCodecs 14:50:36 ... experiments and feedback 14:51:08 ... Chrome 94 will ship the API publicly 14:51:30 -> https://web.dev/webcodecs/ web.dev article 14:51:47 cpn: how to do media packaging 14:52:07 ... developer feedback is very welcome 14:52:18 ... next thing is MSE v2 14:52:28 ... cfc for publishing FPWD 14:52:48 ... would include one of the two major features 14:53:00 ... enabling MSE from the context 14:53:13 ... more responsive to user inputs 14:53:27 ... next WG meeting will be next week, Sep-14 14:53:49 ... Netflix raised issues for MSE ISO-BMFF Bytestream 14:54:08 s/one of the two major/the two main 14:54:11 -> https://docs.google.com/presentation/d/1KfhAl7wbk5diRZbMS_vF-yv0_zs6rw3OArKpafl9qHE/edit#slide=id.gea861d0ee4_0_13 #4, etc. 14:54:41 topic: TPAC planning 14:54:50 cpn: really would like your input 14:54:52 s/enabling MSE from the context/enabling codec switching and MSE in dedicated workers 14:55:16 -> https://www.w3.org/wiki/TPAC/2021/GroupMeetings Group meeting wiki 14:55:40 cl: Comcast interested in UI 14:55:57 ... struggling with performance 14:56:07 ... what are the bottlenecks 14:56:26 cpn: tx 14:56:37 ... we'll find dates for discussion 14:57:05 ... joint meetings with related groups 14:57:38 ... we had discussion with C2PA, and asking them to have discussion again 14:57:52 ... also Multicast CG 14:59:03 ... the other thing, we historically do during TPAC is Industry updates 14:59:17 ... CTA WAVE about latest updates 14:59:32 ... HbbTV, IPTV Forum Japan, ATSC as well 15:00:08 will: would like to follow up 15:00:17 ... with Multicast CG as well 15:00:34 cpn: multi-forum discussion would be nice 15:00:39 q? 15:00:42 q+ 15:01:31 multi-forum discussion that includes CTA WAVE sounds good to me too 15:01:47 kaz: given the meeting wiki need to be updated by the end of this week, we should make decision on the date by the end of this week 15:01:58 cpn: yes, let's have further discussion offline 15:02:09 ... some more updates on workshops 15:02:30 ... workshop on wide color gamut and hdr 15:02:38 ... also professional media production 15:02:47 ... our next meeting will be held on Oct-5 15:03:17 ... input and suggestions welcome 15:03:30 [adjourned] 15:03:37 rrsagent, draft minutes 15:03:37 I have made the request to generate https://www.w3.org/2021/09/07-me-minutes.html kaz 15:03:38 ack k 15:03:40 rrsagent, draft minutes 15:03:40 I have made the request to generate https://www.w3.org/2021/09/07-me-minutes.html kaz 17:05:10 Zakim has left #me