Chris: Thanks for joining the call today.
... What I'd like to is have an open discussion about Media Source Extensions.
... This is well-implemented and deployed in browsers, in use by several client libraries.
... So it seems that now is a good time to review and look at possibilities for v2.
... We should gather use cases for a potential update to the MSE spec
... that reflect our collective requirements.

<cpn> https://www.w3.org/wiki/images/8/8c/Mse-eme-v2-use-cases-reqs-wave.pdf

Chris: This document was distributed several years ago by CTA WAVE.
... It includes several use cases, such as client-side ad-insertion, etc.
... Is this document and its requirements still valid?
... Use cases include ad insertion, splicing of differently encoded media, etc.
... There's a section called "Playback of live content". MSE as-is enables
... live streaming, but there are additional use cases not addressed in v1,
... such as fast start up, and switching between streams.
... (goes through section "2 MSE Use Cases")
... Are there other new use cases/requirements that IG members have?
... There are open issues against the MSE spec, marked as vNext: https://github.com/w3c/media-source/milestone/1
... For low latency streaming, issue 21 discusses allowing application control over the buffering model

<cpn> https://github.com/w3c/media-source/issues/21

Chris: The HTML Media Extensions WG that produced MSE has gone into maintenance mode

<cpn> https://www.w3.org/html/wg/

Chris: So we should consider how to proceed with future work to update MSE. Should we recharter that WG?
... Or take our use cases to the Web Incubator CG?
... The Media Playback Quality spec has been moved to the Web Incubator CG.
... This API is intended to give information in real time about rendering quality, metrics such as dropped frames.

<cpn> https://github.com/WICG/media-playback-quality

Chris: The IG should review this draft to see if it's enough or needs any changes
... Any comments so far?

Mark: I co-chair this IG, and also co-chair the CTA WAVE project.
... The document was posted on the list, but MSE was nearing completion at the time.
... The agreement at that time was for new work for MSE and EME to go to the Web Incubator group.
... The approach there is more as a prototyping project, working code,
... rather than spec work followed by implementation.
... Media Playback Quality is doing this, that is my assumption.

Chris: That's my understanding as well.
... So, what we'll need to do is write some specific proposals for the WICG.
... Examples I've seen there often have an "explainer" document that describes the use cases,
... together with a draft spec.
... That would be a possible way we could take this forward, and then get feedback from the WICG.

Mark: There's another issue about this.
... Next generation features based on requests,
... most of the features people didn't think adding it to 1.0 would be good.
... One of the issues that implementers may be concerned is feasibility of changing the media pipeline.
... What would be the changes for media pipeline with usual browser implementations?
... Consider a simple example such as changing the number of audio channels dynamically.
... MPEG transport systems support this. There are periodic messages in the transport stream.
... One could go from a main program, e.g., with English and Spanish audio tracks,
... and change to only English, and then add Spanish again for the main program.
... This is a much smaller change to discuss than one that involves changing codecs or format.
... And it's one that is not supported by the media pipeline with current browsers.
... We should understand what restrictions exist, and how to extend.
... Makes it a larger effort to get implementations.

Chris: I don't think there's anybody from the implementer side on the call to comment on this.
... Let's think about the next steps for the IG.
... We could review the use cases and submitting these ideas to WICG.
... And then review how things progress in WICG.
... But we do need to work much more closely with the browser vendors,
... discussion about implementations.

(Mark rejoins)

Chris: I have another question. Do any of the use cases we're discussing
... have dependencies on changes to technologies outside of W3C,
... e.g., MPEG DASH or CMAF?

Mark: It is absolutely reasonable for the M&E IG to work on requirements.
... Maybe let's prioritize the requirements, which we then submit to the other groups.
... This was recorded on the wiki a couple years ago, but no active work since then.
... We could have impact now, possibly by creating a Task Force in the IG.
... The accessibility guys also could join.

Chris: This makes sense.

Ali: Some comments on MPEG DASH.
... MPEG DASH can work with MSE, but they're not interdependent. DASH works in non browser / MSE environments.
... Looking at the issues reported by CTA WAVE, the biggest pain is ad insertion.
... There's a need to cope with different encodings, frame rates, etc.
... We tried to solve this in CTA WAVE by defining splicing conditions,
... because of the restrictions of MSE.
... If the requirements that MSE imposes could be relaxed, this could be made easier.

Chris: Interesting, could you elaboarate a little on the MSE features that need to be relaxed?

Ali: With many online services, ad content could come from another source than the original video content
... So the codec, frame rate, resolution, audio, etc, may be different to the main program.
... You want to have a seamless transition between the ad breaks and the original program.
... Also, most of the ad content is not encrypted,
... so there's a need to be able to switch between encrypted and unencrypted content.
... It's not straightforward to achieve a seamless transition.

Chris: Thanks Ali. Any comments from others?

Will: A bigger issue for the IG's work, is where this activity to be done?
... There needs to be a good home for MSE v2 discussion.

Chris: I think that the IG is the right place to do this,
... to establishing use cases and requirements.
... But we do need to involve browser implementers as well.
... As Mark said, to understand the constraints with the current implementation architectures.

Will: We can put requirements together, but the real aim is for the browser guys to also agree.
... So we need people from all 4 major browser engines involved.
... We should focus on that, without browser vendors on board we would fail.

Chris: I was hoping the right people would join today, I did invite them.
... But, you're right, we have to have the right contacts.

Mark: We have discussed with browser people, and they do agree with our requirements.
... But the M&E IG is an IG, so we can't write specs ourselves,
... we can only write requirements.
... On the other hand, the WICG can write specs and get implementations.
... This was agreed for both MSE/EME v2 specs, so I think that is the right place,
... and the M&E IG can prioritize our requirements as a series of incremental projects.
... A WG could later take the results and make the draft into a spec, e.g., and updated MSE.
... In the M&E IG have a lot of experience, and can collaborate with the WICG
... and get some implementations.
... I think that could be the procedure we should take.

Chris: As an example, here are some proposals for changes to EME from Netflix:

<cpn> https://discourse.wicg.io/t/proposal-further-work-on-encrypted-media-extensions/2623

Chris: All the browser vendors are signed up with WICG, so they don't have to do an IPR review

Mark: This is a good example, there are 3 items there:
... Persistent Usage Record, HDCP detection, Encryption scheme capability detection.
... Each one would go to a separate repo.
... So another thread in the WICG Discourse for MSE v2 would make sense.

Chris: I think it first requires us to have some conversation with the browser guys,
... to explain the changes we're thinking about, so they're already aware before it gets to WICG.
... I do agree that it's critical to make progress on these features.
... We should review our submitted requirements, and prepare to submit them to Discourse.
... We could draft explainer documents here, using the IG's GitHub and link to those from the posts we make to the WICG Discourse.
... It requires somebody to initiate that discussion.

(silence)

Will: Silence means our agreement :)

Chris: Would anyone take the lead?

Mark: Maybe a TF of the IG is not the right place.
... We can individually/directly input to the discussion by the WICG
... I myself am joining the Discourse would encourage people to follow

Chris: Right. Chris Wilson explained us the WICG's work during TPAC 2017
... Starting a thread there in Discourse is the right approach.
... Individuals could use their own GitHub repos, or there's the M&E IG GitHub repo to host our explainer document for each feature.

Will: So there's nothing about MSE in the WICG discourse yet?

Chris: That's right, so far only EME.
... So maybe this is a good time to bring our requirements,
... and create a separate thread about MSE.

Will: Also there's currently no incubation itself happening on MSE or EME?
... How to start a new incubation flow?

Chris: I don't think anything can happen automatically,
... posting to Discourse may be enough, or may need offline discussions with browser vendors.

Mark: There is a MSE related group in WICG, actually, Media Playback Quality.
... It's transitioned to an incubation project.

<MarkVickers> https://github.com/WICG/media-playback-quality/graphs/contributors

Mark: Looks like it's still active.

Chris: It would be great if someone could kick off our requirements,
... but we're short on time, so we don't have to decide now.
... We can discuss offline or on the mailing list.
... Given the discussion today, it's good timing to restart the discussion on MSE v2.
... any other points for today?

(none)

[adjourned]