Meeting minutes
Media Source Extensions v2
cpn: Topics for this meeting:
… 1. Rechartering discussions lead to questions about MSE V2 and what is in-scope
… 2. Media Session API; feature prioritization and scoping
jya: we at apple have been working with Chrome with a solution to low memory devices and eviction
… Are working on a new proposal, a Managed Media Source object, with slightly different behavior from Media Source
… The big difference is that Managed Media Source will tell the page when it wants to append data, and can evict data from the buffer without interaction with the page
… It includes some ideas from MSE v2
cpn: Can you share the issue #s?
jya: No issues yet; exists in a Google Doc at the moment. Main goal is just to get feedback from the community.
… Mostly a reaction to getting MSE working on low-power mobile devices using high-power-usage 5g networks
cpn: lets look at the scoping first; and arrange for jya to walk the group through the design of the API
gregwf: I'm working on getStatusForPolicy() but don't have an update today
cpn: from the chartering perspective we don't appear to be overcommitting ourselves.
https://
cpn: Matt had identified issues (linked above) as the main issues he intended to clean up for the MSE v2 work
dale: We on the chrome side don't have the bandwidth to move forward anything that doesn't already have cross-browser buy in
jernoble: it seems we need to determine which are important for v2 and which we could drop
dale: we don't have tests in the spec for promise, also play through gaps is popular, but not something we have bandwidth for
dale: the items that have already been landed in the spec are those that have already received the most requests for
dale: we're limited on bandwidth for both spec and implementation work
jernoble: something that might help with v2 is to get input from the video developer folks from FOMS, to collect requirements
… so before we drop doing the work, we want to directly involve some of the developers
dale: a lot of the issues were already put forward by them, so seems unfair to go back to ask them to prioritise
jernoble: we could ask at least. for example, something not covered here is something that allows you to disconnect a media source to another media element while maintaining the buffer state
… it's something i hadn't heard before, but multiple engine authors mentioned it
dale: there is an issue somewhere
cpn: anything from your point of view, mark?
mark: there's too many issues to say, i can do some work but need to narrow it down to things that are already implemented or where there's interest to implement
… we have workers and changetype already implemented and specced. is there anything else in the list planned to implement?
jernoble: i think some things in the list we'd like to roll into the managed media source
dale: we could come up with a proposal and ask in the video-dev slack
mark: we could set a timeframe, label issues as v3
dale: (in Webex chat): v2 = {changetype, workers, managedmediasource?, maybe 1-2 video-dev requests?} v3={everything else}
cpn: that seems like a good package of features that could be a good v2
… Another thing we can do is reach out to the CTA-WAVE community about features they would like in V2
… ACTION: Identify which issues are related to ManagedMediaSource (jya)
<sushraja> is there a link to the managed media source proposal ?
<eric-carlson_> jean yves (in Webex chat): So this is an explainer for the ManagedMediaSource we would like to propose. It stemmed from w3c/
<eric-carlson_> https://
jya: Unfortunately I have to leave early
jernoble: Volunteers jya to identify which issues would be covered by MMS
dale: I volunteer for bringing the smaller issue list to the Video-dev community, after jernoble and jya have pulled in some items covered by MMS into the v2 milestone.
markw_: Lets keep the v2 label but move all the current items out, and create a new v3 label and attach it to all the previously-v2 item.s
cpn: If there's anything we think is currently labeled as v2 and is moved out of scope that we apply a new (v3-proposed?) label so as not to lose track
ACTION: Perform the v2 -> v3-proposed relabeling
ACTION: Identify which issues are related to ManagedMediaSource (jya)
<markw_> Here is the new V2 milestone: https://
Media Session API
youenn: Since last meeting, Tommy and I have gone through the open issues, mark them as enhancement as P1 or ready for PR
… we have some issues where we're not sure
… We might copy the MSE milestone approach
… We want some feedback on the selection, so wondering about the best approach
… We're close to having a selection
… You identified a few issues needing prioritisation discussion?
youennf: Yes, the longer we wait on some of these, the harder they become to ship
… Is there consensus from user agents that we should tackle them sooner rather than later?
… One issue involves a larger change, #228
<ghurlbot> Issue 228 [open] Add a way of detecting which actions a UA supports
youennf: We could start a discussion on each issue, but we want to know what the priority is
cpn: If we have the right people here we could look at the prioritisation, without going into detail
youennf: Same-origin restrictions, we could do the same with media session. Is there any interest from Chrome and Mozilla to work on that?
… The two first issues relate to iframes, so in the same buckegt
tommy: from Chrome point of view, I don't think we have plans to implement those. if there's developer feedback to say they're v1 worthy, we could look at it
youennf: difficult to restrict if only one browser is doing it. this is why i'm cautious, and leaving to v2 would make it harder
… so i'd be tempted to mark the feature policy integration as v1, then hope that user agents can synchronize on shipping that
… so marking 221 is good? and 194, which is more feature level, we could leave to v2?
tommy: seems good, 194 is an enhancement so less backwards compatibility risk
youennf: 228 was being pushed by Chrome, can you check if there's still interest to make the change and handle the backwards compatibility issues?
tommy: i'll check with francois, to be sure
… seems like a developer ergonomics issue
youennf: that's all I wanted to talk about on media session
<Xiaohan> [I have questions on EME at the end if we still have time]
EME
xaiohan: We have issues tagged as EME v2 and EME v2-bugfixes. Do we still need to triage those for EME v2?
cpn: last time we discussed not pursuing the existing session API
gregfreedman: are there issues that you want to get in FWPD?
xiaohan: I can look to see if there's anything important. If we don't think those are important for EME v2, we can tag them as v3
gregfreedman: We can talk later
xiaohan: Another issue related to EME storage, there's also DOM storage, a clear-site-data header that sites can set. How should EME persistent data behave?
<markw_> Both the milestones have been renamed: V3 and V3BugFixes. We can move any that we intend to address in V2 to the new V2 milestone.
xiaohan: I'll file an issue on that
cpn: i'd suggest only re-label issues if we need to reprioritise. The main thing is getting the feature additions for v2 FPWD
TPAC planning
cpn: TPAC is in September, would be good to know if you'd plan to travel
… I'll raise a GitHub issue, please give an indication there
[adjourned]