– DRAFT –
MEIG monthly meeting

TPAC 2022 planning

ChrisN: We could meet in person at TPAC, good opportunity for cross group meetings, but not sure which other groups are meeting

Jake: We may organise something for the Multicast CG, but I'm unlikely to travel

John: Any responses to your GitHub question?

ChrisN: Not too many

<kaz> TPAC Logistics questionnaire (Member-only)

Kaz: There's a questionnaire that we should look at. Related groups should meet at TPAC. I'd like to ask your ask your interest in digital twin services. WoT can think about the hardware, publishing about the content, and VR
… It could be a possible keyword for potential joint meetings
… It's virtualisation of hardware as cloud services, so the representation, UI for that kind of service can be implemented by immersive web tech and 3D videos etc

ChrisN: Suggest starting a thread with different group chairs, and we could organise it

Kaz: Start with some kind of brainstorming, to find out which parts people are interested in

Overview of Media Technologies for the Web

Chris: https://w3c.github.io/web-roadmaps/media/

Francois: The spec status and implementation status are outdated. Don't need feedback on that, I need to fix the tooling to update those
… Moving specs from exploratory to work in progress to well-deployed. The feedback that would be interesting would be new things that we're looking into but not captured yet
… Also happy to take feedback on the overall structure

Chris: Open question about TV video plane resolution, Screen object rather than video-* media queries
… For EME, drop Persistent Usage Record
… PiP API and caption rendering. There's a proposal for a PiP API for arbitrary content that could be useful for that. I've also seen Mozilla have been working on WebVTT rendering in PiP windows
… https://blog.mozilla.org/en/products/firefox/firefox-picture-in-picture-rolls-out-subtitles/
… Great for WebVTT, but what if you're doing your own custom TTML rendering?

Francois: in Firefox it's a browser-level feature, not with the PIP API

Jake: Ultra-low latency CMAF, you have to call dash.js differently. Is that covered in rendering here?

Francois: Are those changes at the dash.js level, that's a layer above this document

Chris: Chrome feature for low latency video mode?

Francois: Would make sense to document if there's a specific way to handle chunks to trigger a browser's low latency mode
… If dash.js does something special there, we'd want to capture it

Jake: Most discussion is at the higher layer, but if I find a resource, I'll let you know

Chris: Audio output rendering, MC API has spatialRendering capability

Francois: I think that's still an open question

Chris: Could deliver different audio encodings depending on speaker configuration, if there's a way to report that from the browser

Francois: Audio Device Client is no longer being worked on

Chris: Similar to AudioWorklet?

Francois: Had more configuration options, sample rate, which AudioWorklet doesn't give you. There was a need to expose something lower level
… Motivation was allowing cross-compilation of audio libraries

Kaz: This page in the document describes media related technologies in general. On the other hand, if we think about a roadmap for media handling, that should describe our expectations for future technologies and when they should be standardised
… If the purpose is to explain the current status, we should clarify and think about which part should be handled by which group. There's so many topics here, we can't handle it all in this group

Francois: We renamed the document to say that it's not a roadmap. The goal is to track what's going on and identify which are potential useful features. MEIG should prioritise things, and then work with other groups to push those features
… The document is a first step on that

Kaz: Do you want to ask MEIG to update this page directly?

Francois: I'm acting as the editor

Chris: Editorial help from MEIG members would be welcome
… But also, input to identify emerging needs is helpful

Kaz: Clarify which sections are to be edited and how
… It's too big and I'd like to suggest we start with the topics we're interested in first
… Who is interested in which topic today?

Chris: Could jump to the distribution section, to look at multicast

Jake: May be too soon for that. Perhaps next year

Francois: It's there as a feature not covered by ongoing work, so we could move it to exploratory work

Jake: Good idea
… The current goal is that not much changes at the web API level

Francois: The document also allows us to create a list of groups, so we can include Multicast CG there

Jake: https://github.com/w3c/multicast-cg and https://www.w3.org/community/multicast/

Francois: I'm happy to write some words for Jake to review

Kaz: As a starting point, have a brainstorming, and think about how to describe the ideas

Chris: The WebRTC DASH requirements could be good to include

Jake: Is it under distribution, or rendering?

Francois: Rendering doesn't cover WebCodecs right now. But it's OK if we mention technologies in multiple pages. We have WebCodecs in Media Processing

<jholland> maybe a link to https://dashif.org/webRTC/#documents under exploratory work

Chris: Is WebRTC Insertable Streams included in Processing section?
… But what if you're doing segmented delivery and MSE rather than WebRTC delivery. Needs use cases?
… Also the outcomes from the media production could be interesting here

Francois: The Web Media API spec is also interesting, should match the well-deployed sections in our document. I'll look at that

Francois: Main question is what's missing?
… Questions about Media Session. But there may be other things. Interested to add those

Chris: For DataCue, we separate DASH emsg handling from DataCue itself, to progress them independently
… Also, the MEIG thread on frame accurate rendering and seeking

Francois: Canvas rendering, where you control the pixels, Lightning.js framework

Chris: How to suggest changes? Can we file GitHub issues?

Francois: And I'll update the tooling

Chris: Next meeting is 7th June, agenda TBD

<kaz> [adjourned]