Meeting minutes
<Matt_Wolenetz> Frank Liberato and I will join call soon
MSE sourceObject MediaSourceHandle
cpn: https://
<Matt_Wolenetz> https://
Matt: The question I'd like web author input on is what the UA should do if the handle that's being used for a media element, so assigned successfully
… What should happen if that handle is transferred away?
… Perhaps, the UA should allow the transfer away, but internally trigger a media element error path, that's option 1. There may be less interop in WPT: when should the error fire, etc?
… Option 2 would be to throw an exception when the attempt to transfer fails, e.g., on postMessage. Seems simplest to me. But Karl wasn't sure that UAs would know when the handles is unset
… I looked into it, there's a synchronous algorithm, so UAs should synchronously know before it's nulled
… Option 3 lets the transfer proceed and the async start of attachment, will eventually find that the internal state of the handle is marked as not there, so will fail async later
… IMO not as good as it should flag the error earlier, and synchronously
… Option 4 is to let the transfer proceed, and then invalidate the current attachment. Not clear, seems vague at this stage
… Option 2 is preferable to me, but don't want to decide unilaterally
Eric: I read through the issue, I haven't had time to form an opinion yet
Matt: I'm refining the Chromium implementation, so may do option 2 unless I hear opposition or suggestion of a different approach
… When a MediaSource is detached it loses state. The question here is once it's been used, what happens when the app tries to do something else with it?
… Should the detach be called synchronously, would developers prefer to know as early as possible
Chris: Any implementation considerations or is more about developer considerations?
Matt: Timing constraints on when the error is dispatched
Chris: What is the input from Karl?
Matt: We both consider it useful to have wider input
Chris: Should we get input from players such as dash.js or video.js
Matt: Seems like an edge case to me, but one we should nail down
… I can take an action item to reach out to those players
Chris: Failing early seems reasonable to me, option 2, so ask and propose that as preferred option
WebRTC Media Capabilities issues
Bernard: We converged on scope that we're covering real codecs only. Any thing else?
Harald: That makes sense, but we need some interface for telephone events, but calling them codecs is strange, but let's not do that
Bernard: Makes no sense to call those things power efficient
Chris: Suggest discussing at upcoming joint meeting, to cover Media Session and Capabilitiies
Bernard: We can make progress in GitHub
Harald: It's close to having a PR ready
Chris: About the Media Session, when to follow up?
… Monday 23rd
Media Session editing
Chris: Thank you Tommy for joining as editor
Eric: We plan to volunteer someone to co-edit as well
Chris: Can help getting you set up as editor
Timed Text WG issue 503
Chris: https://
Gary: If you're using native captions, WebVTT, but you've decided to implement custom controls, the captions do not automatically move out of the way of the controls, which they do with native controls
… There isn't a good cross browser way to move them out of the way
… The question is how to make it how we can do that natively, so use native caption rendering with custom controls but ensure the captions are still visible
… Chrome and Safari provide a pseudo-element for the text track display, but Firefox doesn't do that.
… So we could spec that so you can modify it. But doesn't solve the problem. Controls at the top or middle of the player, and we want captions to overlap those
… One thing I implemented is the cue's line properties, but that has performance implications. A simple is to be able to tell the video element where you're drawing controls and i'll indicate when they're active
… That's like the behaviour with native control bars
Chris: We have contact with the OpenUI CG, who are interested in custom controls. Should we organise with them?
Gary: Yes
Eric: Are you thinking something like the safe area inset in CSS? i.e., a way to describe a region where it's safe to display captions?
Gary: More a region that's unsafe, where the controls are
Eric: How would you describe that?
Gary: That's the question, maybe an overlay div region
Eric: We may want to see if we can do it with CSS
Gary: I haven't gone deep into possible solutions yet, but if it's just CSS, would be good
Chris: What's the next step?
Gary: Probably worth having a bigger discussion about potential solutions
Chris: Happy to organise
… Just let me know when you're ready
Horizontal reviews
Chris: We have a mixed picture of horizontal reviews
… I put together a summary: https://
… Let me know if it's not accurate to your understanding
… We should request reviews, and complete self-reviews where appropriate
… I started doing some, but help is wanted!
… Some specs are implemented across browsers so we may be ready for CR in some cases
Matt: Would be helpful to have pointers to where to initiate reviews
Chris: I can provide that
… We got some good feedback on MSE on accessibility
Matt: That was good, and we identified some specific details that applied to other specs, so I've filed issues for those
Chris: Thank you
… I'll add some info to the slides, and keep it up to date
Matt: Thank you for putting that together. I'd encourage others in the group to help
Chris: Agree
TPAC 2022
Chris: W3C confirmed the venue is booked, so we need to decide by end of May whether to have an in-person element
Eric: I think we should meet. I am planning to go in person, but will have to see how things at that point
Harald: I intend to be there
Bernard: Me too
Chris: So I'll update the GitHub issue, and we'll prepare an in-person TPAC meeting unless there's objection
Monthly meeting scheduling
Matt: Should we reconsider the scheduling of these calls?
Chris: Only a few people joined last time. Two proposals: One is just to use 2pm Pacific as regular time, other is to continue to alternate but move to 9am instead of 7am. Any opinions?
Eric: Alternating is good, 9am makes it easier
Chris: I'll propose that to the WG and we can continue on the present schedule until new times are confirmed
Next meetings
Chris: 23 May for Media Session and Capture Handle Actions, then 7 June for next monthly meeting
[adjourned]