Meeting minutes
Move Media Playback Quality to FPWD or to the HTML specification
mounir: Some comments from Chris during the call for consensus
cpn: When we discussed it last time, we talked about drafting some criteria to understand when it's a good idea to move the spec into HTML and when to publish it as standalone.
… I'd like to understand better what criteria we're using here.
… Is it because of the size of the spec?
… Is it because of the amount of patching of HTML algorithms that we do? In which case something like MSE, which patches HTML algorithms, would be a good candidate too.
mounir: If we had infinite time, we'd write something. You're right that the size of the spec matters here.
… Domenic would like everything that patches HTML to be merged with HTML. The general feeling in this group last time we discussed is slightly different.
… MSE/EME, not going to merge.
… Picture-in-Picture could be discussed but, from my perspective, it should not move, because it defines specific thinks as well on top of a small amount of monkey-patching.
… What I'm hearing from you is that you would like to see some shared set of rules. Does it have to be formal?
cpn: I'm comfortable with something less formal. What you just explained is fine.
… It could be a resolution in the minutes.
… I'm personally happy with the way you just explained it.
Matt_Wolenetz: Also happy with the direction. I would not like MSE to move to HTML, as this would complicate editorial work significantly.
… Two options in the call for consensus: FPWD and merge back to HTML. What are the differences?
mounir: If we publish as FPWD, it stays within the group and moves to the Rec track. If we move it to HTML, it would no longer be part of the group's list of deliverables.
<Matt_Wolenetz> I was confused - I thought both bullets in the CfC began with "I support". But the second begins with "I object".
mounir: Francois, should we run another CfC?
Francois: We should just record a resolution here, and I'll pass the request along internally to W3M so that it gets discussed in the next W3C / WHATWG call.
<mounir> PROPOSED RESOLUTION: merge the Media Playback Qualityspecification to the HTML specification.
<mounir> PROPOSED RESOLUTION: merge the Media Playback Quality specification to the HTML specification.
Francois: Approval from both sides is needed to effectively do the transition
Resolution: suggest to merge the Media Playback Quality specification to the HTML specification.
Francois: We'll probably need an editor to do the work once we get the green light
mounir: ChrisC should be the hero.
Review group milestones
Francois: The WG has some milestones defined in the charter. We'll miss the milestones, but that's usual.
… Would be good to update those, to show progress, milestones for publication
mounir: With regards to Media Capabilities, it could go to CR. I was hoping ChrisC would be here to tell us about it, it went through a lot of changes.
… We may need to split the spec if we go to CR.
ChrisC: I'm here, actually
… The major part of the spec that are still in flux is the WebRTC additions. There are also ongoing discussions related to CMAF.
… I'm not familiar enough with the process to say whether that should block the transition.
mounir: As far as I know, when we go to CR, we should freeze the scope.
… After CR, the goal is to have tests, implementation report.
Francois: Process 2020 makes it easier to update CR. You get director review to transition to CR and no new feature additions. In practice, many specs transitioned back to WD to be updated.
… With P2020, the first transition is as before, but it can publish new CR Drafts as needed without Director approval. These drafts can add new features or change anything
… Once the group is happy it can request transition to Rec with director's approval
cpn: Similarly, it may be good to remain at the draft level while discussions with CTA WAVE are ongoing, to show we're still considering potential updates
ChrisC: Absolutely.
Matt_Wolenetz: MSE. Some feature capability / detection discussions. In-band support, etc.
… We have a few features that are at least implemented in one browser
Francois: FPWD triggers call for exclusions, so could be good to have some of the features you want in there before publishing
Matt: That could be doable in Q1 2021
mounir: Moving on to Picture-in-Picture
… Only a couple of issues left for CR?
<Matt_Wolenetz> (MSE FPWD Q1 2021 including initial features like SourceBuffer.changeType(), but not necessarily the rest of ongoing feature work that will be in V2 also.)
fbeaufort_: Regarding the spec, the only outstanding issues are disabled Picture-in-Picture attribute, auto pip attribute, and the one I wanted to talk today
mounir: The auto pip attribute has not been launched by anyone, right?
fbeaufort_: Right
mounir: It could be dropped from the spec.
… About disabled?
fbeaufort_: Safari was pushing back.
peng: My understanding is that we're not going to implement that. The motivation is to give the user the option, but not give the web site the control of this.
mounir: One option would be to make support for the attribute optional
fbeaufort_: That's already the case in the spec.
peng: Yes, we support that option but don't do anything.
mounir: OK, let's keep that for later, and move to Media Session.
… Becca is not here. The main issue that we have with Media Session, is that we are missing two implementations. That's not officially a blocker to go to CR, but it will block publication of a REC.
fbeaufort_: I believe that Media Session shipped in Firefox. Maybe not the whole spec.
mounir: OK, then we need to check what can be shipped, indeed.
fbeaufort_: Firefox 75 supports media session "basic", and 76 supports media playback state
mounir: OK, that's good.
Action: Mounir to review Media Session API for CR
mounir: Autoplay Policy Detection, we talked about that in the past. Initially, Google and Firefox offered editors. The person from Google moved to another team. Essentially, the biggest issue is with finding an editor.
… If someone could volunteer, that would be good!
… Anyone interested?
[silence]
mounir: Finally, MSE and EME. FPWD Q1 2021. We don't have a FPWD for either of those for the time being.
… For EME, what is the update?
gregwf: Joey is doing most of the editing work. There hasn't been too much work from an editing perspective.
Action: Mounir to check with Joey about FPWD for EME
mounir: Targeting Q1 2021 would be good so that we have them on the Rec track before we re-charter.
Francois: For things published in /TR, it's possible to automate publishing updates there
chcunningham: If we're talking about rechartering, we should talk about adding WebCodecs.
mounir: Yes, we talked about it when we first chartered.
Francois: Web Codecs is included in the list of potential normative specs, so can be added without rechartering
Matt_Wolenetz: Do you know about any pros/cons about automatically updating TRs?
Francois: It allows you to trap errors early on, e.g., things that block publication rules. Some groups are used to updating specs but not necessarily with group consensus, so may want a distinction between the draft and what's on TR.
… I don't see any cons really
Matt: Any changes needed to our spec repos to do this?
Francois: No, just need to go to FPWD, which requires a formal process step before automating
Should PiP video removed from the DOM leave PiP?
fbeaufort_: In Chromium, the video is paused when we move to another document, per the HTML spec, but not in Safari.
… The question is whether it is a bug in Safari, or whether the plan is to update the HTML spec.
peng: We had an internal discussion about that. It would be good to update the HTML spec if possible.
… PiP is a special case, the recommendation makes sense for inline video.
mounir: One challenge is if, as a group, we go and ask to update HTML, the obvious question will be: "PiP should be merged in HTML", because then the HTML spec would reference Picture-in-Picture, which references HTML.
… It would be good if Safari has strong use cases to keep this.
… Is there any use case that you're aware of that you're trying to solve?
peng: It's hard to say. We changed the behavior because we believe it was a bug. Your point is you don't think it justifies the change?
mounir: It may not be strong enough, unless it really breaks some behavior. We need something that would make it a stronger argument.
peng: I need to discuss with Jer and Tess about that.
mounir: Yes, please and go back to the issue to explain the rationale.
fbeaufort_: Yes, if you can update the GitHub issue, that would be great!
peng: OK, I will follow up.
mounir: Thanks all, happy end of 2020 to everyone, and see you all in 2021!