Meeting minutes
Charter
cpn: We've lost a bit of time. Let's review the agenda.
cpn: A short update on the CFC. We then have a couple of other topics. Some webcodecs related. We didn't have time on previous calls. Lets make sure we have time.
cpn: Some other administrative items to go through.
cpn: On the CFC. I want to make sure I'm caught up with Jer, before I give our decision. We'll share our response shortly.
cpn: Any comments or questions before I proceed? :nothing:
cpn: We'll discuss the rechartering now. Each company needs to rejoin the group. Please review the charter and advisory committee.
cpn: There's a 45 day grace period for reviewing before you may be removed from the group.
Media Playback Quality
cpn: The next thing is Media Playback Quality.
cpn: There's a new MoU that's been signed between WHATWG and W3C. We agreed to migrate media playback quality to the html spec.
cpn: Is someone available to do the editorial work?
cpn: We would need to take the step to mark the existing W3C document as superceded -- or whatever the labeling process is.
cpn: It's not a huge amount of work. Let us know if you have any availability.
dalecurtis: Since chcunningham isn't here I get to volunteer him.
MSE v2 FPWD
cpn: Matt wanted to discuss FPWD v2, but isn't here today. We should get all the major items in the spec so it's ready for a patent-exclusions perspective.
dalecurtis: Matt is out sick today.
cpn: I'm not sure what's remaining. There was mention of codec switching, unbuffered ranges, -- unsure of spec state.
cpn: Lets follow up with Matt.
cpn: Those are the items. Jer has added an item. Do we have time for it?
jer: I added it to the end if we have time.
cpn: We have two issues on webcodecs
cpn: are those the right two issues?
dalecurtis: Yes, maybe one more but might be too close to windows/worker
WebCodecs - Should ImageDecoder IsTypeSupported be (a)synchronous? (#213)
<cpn> https://
dale: When we originally wrote it, it was synchronous, then made async to align with the video and audio API
… We mostly aligned on async, but Paul felt sync was still viable
… Waiting to hear if arguments had changed from Apple's point of view?
Jer: From my point of view, it's still a benefit to throttle requests to the API. Agree it's not inherently async
… I was swayed by Eric's argument: the only alternative to throttling is lying
dale: Paul indicated he didn't want to block on it. I suggest resolving as async
PROPOSED_RESOLUTION: We'll make ImageDecoder IsTypeSupported asynchronous
Resolution: We'll make ImageDecoder IsTypeSupported asynchronous
cpn: Unless there's anything more, we can move on to the other issue on hardware acceleration.
WebCodecs - Is exposing hardwareAcceleration a good idea? (#239)
https://
Dale: Hardware acceleration is not a hint, Youenn prefers it to be a hint, but not be hardware acceleration
… More privacy conscious that way. Other thing is naming. Do we keep hardwareAcceleration? Other names may be more ambiguous, harder to define
… Paul said codecPreference may be hard to implement interoperably
Jer: Are these fields optional. Do we need a "no preference" option?
Dale: Could go either way, it's more a style question
… Having a dual value, or no-preference is fine. Having a hint it's clearer
Jer: Can we align more with the media capabilities language - which could support WebCodecs in future? Aligning concepts could be good
Dale: We use powerEfficient to mean hardware encoded. Different terms but functionally the same
Jer: Powerefficient is ambiguous, up to the UA to interpret. Hardware accelerated isn't
… Then we have to come up with workarounds for the assumptions sites make
Dale: It's an output parameter in WebCodecs
Jer: You could use the value as input to a polyfill
… My preference would be to align terminology as input to Media Capabilities with those used in WebCodecs
Dale: Chris has tried to separate those
Harald: Arguments against using hardwareAcceleration made in the past, it's meaningless. If Media Capabilities has a term that's not hardware acceleration, let's align with it
Jan-Ivar: Not clear to me what a developer is asking for with hardwareAcceleration
… Sounds like a failed abstraction. Do they want efficiency? I worry developers making decisions where the UA is better placed
Dale: WASM decoders, or force software decoder to get more frames out due to limitations with hardware decoders
… Specific reasons: Zoom using it to select WASM decoder
Jan-Ivar: That sounds pragmatic
Dale: The hints would keep compatibility with what they want. hardwareacceleration is a misnomer really, open to other names
… could have codec preference, with prefer hardware/prefer software
… If we agree that optional makes sense, don't have a strong opinion on naming
Jer: Implementation-wise, prefer hardware/software should be fine. But the interoperability question is hard, so easy way is to make it vague
… Prefer hardware is harder to get out of that spec bind
… The difficulty is in writing the spec text for what the values mean, and that we don't back ourselves into a hole
Dale: For WPT, we'd expect a playback test looking for a frame passes with both
… Don't want it to be fingerprintable - despite hardware and software giving different outputs in terms of frame quality
Jer: More comfortable knowing it's not a hard requirement. Should we take this to GitHub to get responses from others?
Dale: Would be good if Bernard or Youenn wants to reply
… Can give it a bit longer, and come back with an agreement among Dale, Bernard, etc
jer: sounds like we're done with that item. lets move on to my agenda item.
cpn: Yes that sounds fine.
jer: https://
Introduction to Media Session Coordinator
<hober> https://
jer: In last WWDC, we announced synchronized playback across multiple devices.
jer: Functions similar to how MediaController used to within the page.
jer: We have an experimental feature in the GitHub.
jer: based on the media session specification. You will get play/pause commands from the remote session locally.
jer: There is a new object called the coordinator to issue these commands to everyone else in the session.
jer: You will get back media session actions. It's currently an experimental web platform feature available in Monterey.
jer: Another point is it's easily polyfillable.
jer: If anyone has any javascript API, you can implement your own coordinator -- with no special details of coordination with this API.
jer: Please take a look and let us know what you think
<cpn> Dale: Looks interesting from our side, no objections, looks useful for multi-device ecosystems
dalecurtis: We looked and it seemed interesting, but no plans and no objections.
jer: There is another specification on media timing that presents an external time source for synchronized playback.
jer: It would allow frame accurate playback over a media wall. Both are interesting areas of synchronization.
gkatsev: Can you use this to sync up two players on the same page?
jer: It's meant to represent remote sessions.
jer: MediaController is more the API for doing this locally. Media timing could work remote and locally.
gkatsev: Looks cool.
jan-ivar: I think it should be setActionHandler. I proposed a another API on the issue tracker.
cpn: Lets move this to our next meeting.
cpn: I have a question about the coordinator. Are you saying. There are a number of steps. How do you establish the group of partipating devices? What's the scope of the coordinator proposal?
cpn: How much do I have build as an application developer?
jer: Hopefully you don't have to build very much. Different applications will have different ways of grouping, but player shouldn't care what the synchronization mechanism is if the API is defined well.
jer: Areas of future improvements are how do I initiate a synchronizable session?
jer: We wanted to put something up for the group before tackling the more complicated issues around new session.s
dalecurtis: Chromecast had a bunch of requirements around this in the past, but just uses Media Session.
<tidoust> [To some extent, this seems to follow the same approach as the one taken in the Second Screen WG with the Presentation API and Remote Playback API: start with the API, then look at protocols to improve the interoperability story across devices]
jer: All APis are public so Chrome or Firefox can implement if they so choose.
cpn: We wouldn't necessarily want to be tied into a certain ecosystem.
cpn: We've built our own watch together synchronization mechanisms.
jer: if we had a web api for synchronization then BBC would only need to implement one API.
jan-ivar: We'd wish to see this standardized in more environment.
jer: One of the impetus here was to help all the services who have rolled their own watch together APIs, none of them work on the web.
jer: Hopefully we can end up with a common API surface. It does put a lot of impetus on the UA to implement this.
jan-ivar: One way to view this is like geolocation.
jer: That's my pitch.
jer: We're actually at the end of our agenda items.
cpn: That we are. Our next meeting is august. We should cover Media Session capability detection in that meeting.
cpn: We should have more on WebCodecs then as well.
Meeting ended.