A new version of the W3C Patent Policy has been reviewed by the advisory committee and adopted by W3C. All new groups will operate under the new patent policy. Existing groups will continue to operate under the previous version of the W3C Patent Policy until they re-charter, but they may choose to switch to the new patent policy right away.

The main change is that, under the new patent policy, royalty-free commitments apply earlier, at the Candidate Recommendation phase, and not only at the Recommendation phase. In non legal terms, the new patent policy encourages implementations and usage earlier on.

If the group agrees to switch to the new patent policy, a new charter will be issued early December. Only change in that charter will be the patent policy. The end date, the scope, the list of deliverables, and everything else will remain untouched. The adoption of this new charter will be automatic (the new charter will not be sent to the advisory committee for review in particular). The only hiccup is that participants will have to re-join the WG afterwards.
 
Regardless of what the group decides today, it will have to switch to the new patent policy next time it re-charters. The current charter expires in May 2021. That is not too far away. That said, the group may publish a few Candidate Recommendation by then, which could take advantage of the new patent policy.

Deadline for requesting a switch to the new patent policy is 27 November.

Cc @mounirlamouri, @jernoble

Should we meet at the TPAC F2F if it happens? For how long? Should we host a WebCodecs discussion?

The specification is now widely implemented. We could either embrace the extension to the media section of the HTML specification and publish a FPWD or merge everything into the HTML specification and close this work. Unless there are important follow-ups we would like to do first?

/cc @tidoust @jernoble

Look at w3c/media-capabilities#131

This came up during our TPAC 2019 face to face (minutes) in the context of the discussion for Picture-in-Picture.

We were wondering whether the parts of HTML around media (HTMLMediaElement, HTMLAudioElement, HTMLVideoElement, TextTrack, ...?) should be moved out of the core spec in order to be owned by the Media WG as the area experts are part of this group.

@jernoble volunteered to see with @hober what we could do.

TPAC 2023 is planned to be held in Seville from 11 to 15 September 2023. These will be hybrid meetings with in-person and remote attendance, as last year.

Groups are being asked to give an indication of their meeting plans, by 8 May.

My suggestion would be we do the same as last year: 4 hours of meetings, in two 2-hour sessions.

If we were to plan a hybrid Media WG meeting, would you want (or be able to) join in person in Seville?

Please indicate your preference on whether you'd plan to travel. This is to get a sense of the number of people who would be there in person, so we have an appropriate sized room. I realize this is very early, so not looking for you to commit right now.

• 👍 if you would plan to join in person
• 👎 if you can only join a virtual meeting

We can also organize joint meetings with other groups as needed, such as Audio WG, Web RTC WG, Timed Text WG, Media & Entertainment IG, Please leave a comment with your suggestions.

We're progressively renaming default branches of W3C repositories to main. This is a meta issue to track Media WG repositories for which that still needs to happen:

• w3c/autoplay
• w3c/encrypted-media
• w3c/media-capabilities
• w3c/media-wg
• w3c/mediasession
• w3c/picture-in-picture

Migration should be mostly transparent, except branch names of local clones will have to be updated.

The idea is to check off items that have had an issue open (ideally listed next to it afterwards) or were done when no issue was actually needed.

Actions

• mounir to add non-normative suggestions for behavior for pip window if remote/full screen engaged from main player w3c/picture-in-picture/issues/175
• jer and mounir to talk to FOMS organizers about interest to co-host a Media WG F2F #12
• jer to discuss moving media out of html w/ hober #11
• chcunningham to add examples to the Media Capabilities spec w3c/media-capabilities/issues/147
• Joey_Parrish to add language to the privacy path WICG/hdcp-detection/issues/13
• Joey_Parrish to look into reducing the number of HDCP versions we expose to collapse to those actually used WICG/hdcp-detection/issues/12
• jer and mounir to create an issue on the media-wg repo about the resolution process, #2
• jer and mounir to send CfC for publication as FPWD of Media Capabilities, PiP and Media Session the week after TPAC, #4
• markw and GregFreedman to figure out who edits which spec (MSE/EME) among themselves
• mounir to swap his name with chcunningham as editor of Media Playback Quality #7
• padenot to check whether someone from Mozilla can become editor of Media Session #6
• scottlow to check for possible editors for MSE and EME #9
• chcunningham to work with jer and propose an API that does some sort of eventing in a backward compatible way, and that converts the VideoPlaybackQuality object to a dictionary
• mounir to talk to foolip to double check whether versioning is needed for MSE v2 WPT w3c/media-source#242
• tidoust to exchange with wolenetz on setting up MSE repo, updating boilerplate, ReSpec, etc. w3c/media-source#241

Resolutions

• Expose an API to expose key ID information from initialization data in order to find existing sessions w3c/encrypted-media/issues/467
• The Media WG will have monthly calls, and encourage ad-hoc meetings on specific issues, #3
• Add Greg Whitworth as editor of Media Capabilities #8
• Joey_Parrish to prepare a PR to integrate encryption scheme proposal in EME (W3C repo) (done, didn't track)
• we can revert the framerate attribute back to a double (done, didn't track)
• using a hint specific to low latency instead of content hint (done, didn't track)
• Remove corruptedFrames from Media Playback Quality w3c/media-playback-quality#5

/CC @tidoust @jernoble

The Media WG's charter happily asserts that all specifications developed by the group will be published as Candidate Recommendations (CR) by the end of 2020. I'm raising this issue to track the publication status of the group's deliverables, and discuss an updated timeline:

• Media Capabilities: Some open issues that still need to be addressed. Which ones prevent publication of the spec as CR?
• Picture-in-Picture: Publication as CR is tracked in w3c/picture-in-picture#184. Could a CR be published soon?
• Media Session: There are open issues to address. What is a reasonable updated timeline for the spec?
• Media Playback Quality: The open question is rather on whether to publish the spec as a standalone spec or to merge it within HTML, tracked in #17.
• Autoplay Policy Detection: The group has not discussed this deliverable recently. Does it still plan to work on it?
• Media Source Extensions / Encrypted Media Extensions: Good progress on flagging issues. Some updates have made it to the specs, other updates have not. It would be good to publish the revisions as First Public Working Draft (FPWD).

I note that Process 2020 (under which the group now operates) makes it easier to iterate at the CR phase: no need to get back to Working Draft after publication of an initial CR, the group can just publish new CR Drafts whenever needed (without having to get approval from the Director, and regardless of whether the new drafts introduce normative changes).

He was volunteered by Scott, IIRC :)

After the regular agenda issues for the Media WG will be resolved, the rest of the Media WG meeting will be a join meeting with the CSS WG. If the regular agenda is small enough and not urgent, we may have the full meeting dedicated to the joint meeting and punt the other topics.

The topic will be: w3c/csswg-drafts#5044

Both MSE and EME repos have an open set of issues flagged with "v1", "v1next" and other labels that were meaningful before these publications got published as Recommendations. It would be good to skim through them and identify those that the Media Working Group intends to address in the iteration of the spec it is working on, and those that go beyond the envisioned scope:
https://github.com/w3c/media-source/issues
https://github.com/w3c/encrypted-media/issues

This is an issue meant to track the work being done:

• Get Editors blessing
• Send CfC for inclusion in the WG and FPWD to Media WG
• Send Intent to Migrate to the WebCodecs repository.

@tidoust @jernoble

As discussed at TPAC 2019, Chris will take over the spec as he has been working on it already.

Do we want to meet or organise any joint meetings during TPAC 2021?

18-22 October: Breakout sessions
25-29 October: Group meetings and Joint group meetings

https://www.w3.org/wiki/TPAC/2021/GroupMeetings

So far, one joint meeting has been suggested: with WebRTC WG, including capture APIs and interactions between WebRTC APIs and WebCodecs.

/CC @jernoble @tidoust

/CC @tidoust @jernoble

We discussed at 2019 TPAC to have our next face to face close to FOMS if there is one in H1 this year. I don't think we heard of a H1 FOMS yet but I'm about to send some folks an email to double check.

Assuming that doesn't work, we should start looking at whether we want to have a face to face. If we have one, I wonder if we could try to merge with other efforts that are not officially related to this WG (yet) like WebCodecs as they could benefit from a f2f meeting.

The current Media WG charter expires end of May 2021. For some reason, I thought we still had time to prepare a new charter. In practice, we need a new draft charter soon, ideally within the next couple of weeks, at worst end of March, so that we may run the rechartering process (horizontal reviews, review by W3C Management, and then review by W3C Members) before the charter expires (*).

The draft charter is in a separate repo. I prepared a pull request to prepare a possible starting point for a new charter: w3c/charter-media-wg#13

The PR adds WebCodecs to the list of deliverables, and drops the mention of the persistent usage record session feature from the description of EME, as resolved by the group. No change in scope.

Some notes/questions:

• W3C process now allows groups to choose a Candidate Recommendation (with Snapshots) mode where specs remain at the CR phase and never advance to Recommendation (in other words, something close to a "living standard" mode). Does the group want that for some/all of its deliverables?
• Transition of Media Playback Quality to HTML is ongoing (see #17). Depending on how the process progresses in the next couple of months, we may be able to drop it from the list of deliverables.
• We discussed milestones back in December (see #22). I adjusted milestones as best as I could. Feedback welcome!
• Should the scope be adjusted, e.g. to be more explicit about WebCodecs?
• Status and URL may change for a few deliverables depending on whether the group manages to publish Candidate Recommendations and/or First Public Working Drafts of some of its deliverables in the upcoming months. I'll take care of that when needed.

(*) If the group needs more time, we may request a small extension to sort things out.

After two years of virtual TPACs, the W3C team are looking at organizing a hybrid edition; physical meetings with strong support for remote participants. The physical meetings would be held in Vancouver from 12 to 16 September 2022.

Groups are being asked to gauge the level of interest and feasibility for an in-person meeting.

If we were to plan a hybrid Media WG meeting, would you want (or be able to) join in person in Vancouver? Please indicate your preference based on what you know today. We know things may change.

• 👍 if you plan to join in person
• 👎 if you can only join a virtual meeting
• 😕 if you don't know at this stage

Please also comment to share any other feedback you may have. We'll share feedback with the W3C team later this month, so please reply before Friday 25 March.

@scottlow said he will reach out internally. Microsoft used to have editors for these specifications but they are no longer around. Netflix and Google are willing to co-edit so we have two editors and there is no urgency to get a third.

@padenot volunteered to look whether Mozilla would be interested to co-edit the Media Session specification. There are already two editors so there is no urgent need for a new one but wouldn't be bad either :)

I've just posted an invite and agenda for a Media WG meeting next week (Tuesday 11 Oct at 9am Pacific), with some MSE interop issues that @wolenetz has suggested.

But, the meeting overlaps with FOMS. Matt has said he's available, but wondering whether to reschedule or change the agenda depending on who's available.

@jernoble Are you available for this WG meeting?

@karlt - I notice that you're not a member of Media WG, so possibly aren't receiving meeting invites. Are you also available? There's a link to join the WG here.

As raised during today's Media WG call, once a specification has been published to /TR, i.e. after publication of the spec as First Public Working Draft, the Editor's Draft can be kept in sync with the document in /TR automatically (through Echidna).

The main benefit is that there is no way to end up in the all-too-common situation where the document in /TR is way behind the latest Editor's Draft. One possible drawback is that the Editor's Draft may sometimes contain bits that do not yet represent the consensus of the whole group. Given how the Media Working Group operates, that seems unlikely to create issues, but YMMV...

For what it's worth, this has no implication with regards to the patent policy, as publications as First Public Working Draft, Candidate Recommendation Snapshots and final Recommendation remain gated by a group resolution at a minimum.

This issue is to assess support within the Media Working Group to use Echidna whenever possible for all the deliverables of the group.

From 11th of August 2020 call: https://www.w3.org/2020/08/11-mediawg-minutes.html#t01

The list at the moment is the following:

MSE

• Matt Wolenetz, Google
• Mark or Greg from Netflix
• Maybe someone from Microsoft

EME

• Joey Parrish, Google
• Mark or Greg from Netflix
• Maybe someone from Microsoft

The Microsoft question is being addressed in #9.

@mwatson2, can you remind me who is going to edit what on the Netflix side?

I was asked by Chris and others working on Media Capabilities to facilitate a privacy review with the PING.

The current status: waiting for them to confirm that the privacy & security questionnaire is up to date as it was updated 2 years ago.

I was recently asked to consider moving the video.requestVideoFrameCallback spec from WICG to the media WG.

How does the WG evaluate which specs it takes on? Could discussing this be a added to the agenda of the next media WG meeting?

Thank you!

/cc @jernoble @tidoust

The Second Screen WG has a few open issues that need input from the Media WG. I'd like to arrange a joint meeting sometime soon.

• w3c/openscreenprotocol#194
• w3c/openscreenprotocol#233

There may be others (TBD). Please comment on those issues directly if you have input. Thanks!

The Media Working Group maintains the MSE Byte Stream Format Registry, the EME Initialization Data Format Registry and the EME Stream Format Registry. These registries have been published as Working Group Notes. In practice, W3C has no standard way to maintain registries.

The W3C Process Community Group and the Advisory Board are currently drafting a process for registries (see a list of related issues) and W3C is conducting a survey across groups on the topic.

This survey asks follow up questions to the TPAC 2020 Process 2021 presentation. Main questions for the group are the following:

Do we need a Candidate Recommendation phase?

Would your group find value in signalling to the community in a Candidate Recommendation (CR) phase for the Registry Definition to ask “we think we're done, please check, before we ask for a Proposed Recommendation (PR) transition” even though pure registries do not have a “call for implementations”, or should we give registries a process that skips CR? (See Do we need both CR and PR?)

• Registries should have a CR phase to experimentally validate the Working Draft before requesting AC approval.
• Registries do not need a CR phase to experimentally validate the Working Draft before requesting AC approval.
• No opinion

Separate track?

The normal practice is for registries to be distinct, and different from, the specifications that define, embed, or use them. They are maintained differently, they have different approval status, and therefore are published separately. Does your group think we should define registries as being on the W3C Recommendation Track, or should they have their own separate W3C Registry Track (which clearly detaches them from the W3C Patent Policy)? (See Separate track?)

• Separate track is better
• Re-using Recommendation Track as-is is better
• No opinion

Registry definitions and tables

Does your group think your registries benefit from the ability to publish definitions and tables separately? (Not just separate files within the same publication on /TR, but under completely separate /TR shortnames?) (See Must be together? and May be separate?)

• Yes, we need this
• We'd use it if it was available but can live without
• We would not use this
• We think it's harmful

Further comments are welcome as well.

I'd be interested to get the perspective of the group. Any feedback?

Deadline for the survey is 10 February 2021.