20:52:58 RRSAgent has joined #mediawg 20:52:58 logging to https://www.w3.org/2022/05/10-mediawg-irc 20:53:04 Zakim has joined #mediawg 20:53:21 Meeting: Media WG teleconference 20:53:35 Agenda: https://www.w3.org/groups/wg/media/calendar#card-f5ce6901-bcb0-48b6-803e-37cc31bf659b 21:00:19 Matt_Wolenetz has joined #mediawg 21:00:32 Frank Liberato and I will join call soon 21:01:24 Present+ Chris_Needham, Eric_Carlson, Bernard_Aboba 21:01:34 Regrets: Jer_Noble, Chris_Cunningham 21:01:50 cyril has joined #mediawg 21:02:09 present+ 21:02:12 Present+ Tommy_Stiemel, Cyril_Concolato, Gary_Katsevman, Harald_Alvestrand 21:02:17 Frank_Liberato has joined #mediawg 21:03:24 Present+ Greg_Freedman 21:03:38 Agenda: https://www.w3.org/groups/wg/media/calendar#card-f5ce6901-bcb0-48b6-803e-37cc31bf659b 21:04:20 hta has joined #mediawg 21:04:52 Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2022-05-10-Media_Working_Group_Teleconference-agenda.md 21:07:11 Topic: MSE sourceObject MediaSourceHandle 21:07:16 cpn: https://github.com/w3c/media-source/pull/306 21:07:24 https://lists.w3.org/Archives/Public/public-media-wg/2022May/0003.html 21:07:45 scribe+ cpn 21:08:10 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 21:08:29 ... What should happen if that handle is transferred away? 21:09:16 ... 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? 21:10:06 ... 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 21:10:33 ... I looked into it, there's a synchronous algorithm, so UAs should synchronously know before it's nulled 21:11:19 ... 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 21:11:38 ... IMO not as good as it should flag the error earlier, and synchronously 21:12:07 ... Option 4 is to let the transfer proceed, and then invalidate the current attachment. Not clear, seems vague at this stage 21:12:32 ... Option 2 is preferable to me, but don't want to decide unilaterally 21:13:10 Eric: I read through the issue, I haven't had time to form an opinion yet 21:13:53 Matt: I'm refining the Chromium implementation, so may do option 2 unless I hear opposition or suggestion of a different approach 21:15:20 ... 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? 21:16:10 ... Should the detach be called synchronously, would developers prefer to know as early as possible 21:17:02 Chris: Any implementation considerations or is more about developer considerations? 21:17:54 Matt: Timing constraints on when the error is dispatched 21:18:21 Chris: What is the input from Karl? 21:18:35 Matt: We both consider it useful to have wider input 21:19:27 Chris: Should we get input from players such as dash.js or video.js 21:19:43 Matt: Seems like an edge case to me, but one we should nail down 21:20:01 ... I can take an action item to reach out to those players 21:21:16 Chris: Failing early seems reasonable to me, option 2, so ask and propose that as preferred option 21:23:20 Topic: WebRTC Media Capabilities issues 21:23:50 Bernard: We converged on scope that we're covering real codecs only. Any thing else? 21:24:12 Harald: That makes sense, but we need some interface for telephone events, but calling them codecs is strange, but let's not do that 21:24:29 Bernard: Makes no sense to call those things power efficient 21:26:23 Chris: Suggest discussing at upcoming joint meeting, to cover Media Session and Capabilitiies 21:26:37 Bernard: We can make progress in GitHub 21:26:49 Harald: It's close to having a PR ready 21:28:27 Chris: About the Media Session, when to follow up? 21:28:34 ... Monday 23rd 21:30:54 Topic: Media Session editing 21:31:08 Chris: Thank you Tommy for joining as editor 21:31:18 Eric: We plan to volunteer someone to co-edit as well 21:31:58 Chris: Can help getting you set up as editor 21:32:36 Topic: Timed Text WG issue 503 21:32:47 Chris: https://github.com/w3c/webvtt/issues/503 21:33:16 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 21:33:28 ... There isn't a good cross browser way to move them out of the way 21:33:57 ... 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 21:34:39 ... Chrome and Safari provide a pseudo-element for the text track display, but Firefox doesn't do that. 21:35:09 ... 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 21:35:53 ... 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 21:36:02 ... That's like the behaviour with native control bars 21:37:18 Chris: We have contact with the OpenUI CG, who are interested in custom controls. Should we organise with them? 21:37:22 Gary: Yes 21:37:57 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? 21:38:14 Gary: More a region that's unsafe, where the controls are 21:38:20 Eric: How would you describe that? 21:38:33 Gary: That's the question, maybe an overlay div region 21:39:01 Eric: We may want to see if we can do it with CSS 21:39:22 Gary: I haven't gone deep into possible solutions yet, but if it's just CSS, would be good 21:39:42 Chris: What's the next step? 21:40:10 Gary: Probably worth having a bigger discussion about potential solutions 21:40:35 Chris: Happy to organise 21:41:33 ... Just let me know when you're ready 21:42:09 Topic: Horizontal reviews 21:43:20 Chris: We have a mixed picture of horizontal reviews 21:43:29 ... I put together a summary: https://docs.google.com/presentation/d/15KyxeFKx1V5VWbYLK2yELxQQbusfjgVXsADWZHOvIF8/edit 21:44:06 ... Let me know if it's not accurate to your understanding 21:45:28 ... We should request reviews, and complete self-reviews where appropriate 21:45:37 ... I started doing some, but help is wanted! 21:47:22 ... Some specs are implemented across browsers so we may be ready for CR in some cases 21:48:17 Matt: Would be helpful to have pointers to where to initiate reviews 21:48:25 Chris: I can provide that 21:49:08 ... We got some good feedback on MSE on accessibility 21:49:42 Matt: That was good, and we identified some specific details that applied to other specs, so I've filed issues for those 21:49:45 Chris: Thank you 21:50:40 ... I'll add some info to the slides, and keep it up to date 21:51:15 Matt: Thank you for putting that together. I'd encourage others in the group to help 21:51:19 Chris: Agree 21:51:42 Topic: TPAC 2022 21:54:08 Chris: W3C confirmed the venue is booked, so we need to decide by end of May whether to have an in-person element 21:54:34 Eric: I think we should meet. I am planning to go in person, but will have to see how things at that point 21:54:48 Harald: I intend to be there 21:54:59 Bernard: Me too 22:03:00 Chris: So I'll update the GitHub issue, and we'll prepare an in-person TPAC meeting unless there's objection 22:03:09 Topic: Monthly meeting scheduling 22:03:29 Matt: Should we reconsider the scheduling of these calls? 22:04:11 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? 22:04:26 Eric: Alternating is good, 9am makes it easier 22:05:06 Chris: I'll propose that to the WG and we can continue on the present schedule until new times are confirmed 22:05:13 Topic: Next meetings 22:05:34 Chris: 23 May for Media Session and Capture Handle Actions, then 7 June for next monthly meeting 22:05:36 [adjourned] 22:05:40 rrsagent, draft minutes 22:05:40 I have made the request to generate https://www.w3.org/2022/05/10-mediawg-minutes.html cpn 22:05:46 rrsagent, make log public 22:06:06 chair: Chris_Needham 22:06:18 Regrets+ Francois_Daoust 22:06:21 rrsagent, make log public 22:06:25 rrsagent, draft minutes 22:06:25 I have made the request to generate https://www.w3.org/2022/05/10-mediawg-minutes.html cpn