Meeting minutes
Media Session - Introduce a generic skip action as a replacement to skipad
Youenn: Part of the review from the TAG to get a more generic skip action, for services such as Netflix or the like that could use this to skip some content.
… The PR is in two parts: rename the skipad into skip, and define the kind of thing being skipped.
… The user-agent may use the kind to determine what UI to show.
… Initially, the feedback from the TAG was around the lines of having a "skippable: true" flag.
… I'm just relying on the kind information here.
… It allows to customize the skip button.
… The kind information is either at the top of the metadata or in the Chapter information.
… There is room for a default handler to skip to the next chapter if the application is not registering a default handler.
… If the application only sets the kind at the top of the metadata, I'm not sure what the default handler could do.
… Chris Needham suggests that the list of kinds might be too restrictive. Currently, it's an enumeration. If we wanted to add new values, that's doable. And it's feature detectable as well.
… Another feedback from Tommy about a general kind.
Tommy: Some sort of "catch all" default playback kind would seem useful. If we're adding to the metadata at the top level, it would make sense to add something more general.
Youenn: I agree. We could add later something such as song, movie, etc. But since it's tightly tied to skip, that does not seem needed right away.
Tommy: Giving the website too much control could be detrimental.
Youenn: I agree.
… I can ping him.
Youenn: I don't know if others have feedback.
Francois: Chatting with Chris, what we were wondering about is a generic kind.
Youenn: Some "other" value perhaps.
Francois: Yes, would work
Tommy: Could the empty value be used?
Marcos: I'm also worried that we might be too specific here. Also worried that we might end up with opening something and closing something, etc. Where does the list come from?
Youenn: From typical things in a movie and TV shows, looking at what Netflix, Amazon Prime, Apple TV would typically provide.
… What I can add is an "other" value and a note to say that this list is experimental and might be subject to changes.
Jean-Yves: Should we also extend this to Media Session?
… The Media session has an option to skip, forward, and so on.
Youenn: Yes, that's precisely what the PR is doing.
… Starting with renaming skipad into skip.
… I'll update the PR with these two things and ping Chris on GitHub for additional feedback.
Media Source Extensions - Tracks on SourceBuffer in a worker
Jean-Yves: I opened a new issue, #361.
… Currently, the SourceBuffer has a list of track list: AudioTrackList, VideoTrackList, TextTrackList.
… Currently those track related objects are only exposed at the window level, not in workers.
… If we were to expose them in a worker, it would sort of open a Pandora box, because, e.g., a TextTrack can have cues which can embed DOM objects.
… There's also no point accessing these objects from a worker.
… The primary reason to access these objects from a worker is to not being blocked by the main thread, but these tracks will be rendered as part of the main UI anyway.
… You'll be able to access all of these objects from the media element on the main thread.
… My webkit proposal is to remove the verbiage that would expose these objects to workers because that wouldn't make sense in any case, and no one is doing it.
Eric: To clarify, the cues themselves are not DOM elements but there is a method on VTTCue that can return the cue as HTML which of course cannot happen.
… When sites use cues from JavaScript to render them themselves, this involves the use of DOM elements.
… Having them available in a worker would essentially not help anybody.
marcosc: What is the mechanism not to expose them?
Jean-Yves: I believe WebIDL proves a mechanism to narrow the exposure scope of the attributes to Window.
Francois: That would also fix an IDL validation error on our side when we extract IDL from specs because the objects cannot be exposed to worker right now.
marcosc: Any concern with the proposal?
[none heard]
Jean-Yves: I'm wondering about people implementing JS players to see if they have concerns with that.
marcosc: We can certainly ping them.
Eric: It seems that this would be an edge case, and it does not seem too hard to pass the data back and forth in any case.
marcosc: And it cannot be used today anyway.
Media Capabilities - Fixup MIME usage
markafoltz: I submitted more changes to PR #222. Team effort. I think I've addressed most of the outstanding feedback on this PR.
<marcosc> https://
markafoltz: I removed the slot definition and factored out a few things that are going to be similar for audio and video.
… Hopefully, that should clarify the steps when an implementation should return an error.
… I believe the PR matches what implementations do at least for the file case.
… There's still a bit of fuzziness around webrtc cases, but I propose not to hold the PR on that.
… It touches enough of the spec that other work is somewhat blocked by it, so it would be great to move forward on this.
marcosc: I'll review that by the end of the month if not sooner.
markafoltz: If there's additional feedback, I would propose to do it in steps as a follow-up.
marcosc: From memory, one of the checks could potentially throw somewhere. I'd like to look at it again.
markafoltz: Yes, these have been factored out, once you go in steps, you can assume that you have a valid string already.
… We can make progress on cleaning smaller stuff afterwards.
… There's one case where Chrome behavior does not match what's implemented in other browsers. I filed a bug, I think we can fix it.
… I think WPT does a reasonable job at covering the different cases.
marcosc: Would be good to link to WPT in the discussion.
markafoltz: I'll add links.
<markafoltz> WPT for Media capabiliites: https://
marcosc: If that's of interest to anybody, by all means, please have a look, quite an interesting PR!