IRC log of mediawg on 2022-09-16
Timestamps are in UTC.
- 00:00:09 [dom]
- -> https://github.com/w3c/webcodecs/issues/198 Emit metadata (SPS,VUI,SEI,...) during decoding #198
- 00:00:33 [dom]
- DanS: with our metadata proposal, the way to do it is relatively clear, the question is really platform support
- 00:00:54 [dom]
- Subtopic: w3c/webcodecs #371 AudioEncoderConfig.latencyMode (or similar) extension
- 00:01:01 [Bernard]
- q+
- 00:01:07 [youenn]
- youenn has joined #mediawg
- 00:01:17 [dom]
- -> https://github.com/w3c/webcodecs/issues/371 AudioEncoderConfig.latencyMode (or similar) #371
- 00:01:31 [dom]
- -> https://github.com/w3c/webcodecs/issues/405 Fixed audio chunk size support #405
- 00:01:42 [dom]
- tguilbert: these 2 issues may be the same issue
- 00:01:47 [dom]
- paul: indeed, probably overlap
- 00:02:13 [dom]
- ... it's mostly something we need to do
- 00:02:53 [dom]
- ... in terms of codecs it will apply to: most codecs are fixed-size frame, but OPUS, @@@ and FLAC (not adapted to real-time)
- 00:03:04 [dom]
- ... adding it to OPUS registry would work
- 00:03:19 [dom]
- Bernard: 405 is adding ptime - doesn't need to be codec specific?
- 00:03:30 [Bernard]
- Issue 405 is about ptime... should be for all codecs, no?
- 00:03:40 [dom]
- tguilbert: if we expose latency mode on audio encoder, the meaning may differ across codecs
- 00:03:57 [Bernard]
- Bernard: Question about "latency mode": for video, the knob doesn't seem to make much difference in latency...
- 00:04:01 [cpn]
- q?
- 00:04:02 [dom]
- ... so a per-codec setting might be better than a generic low-latency/high-quality toggle
- 00:04:14 [dom]
- Subtopic: w3c/webcodecs #270 Support per-frame QP configuration by VideoEncoder extension
- 00:04:30 [dom]
- -> https://github.com/w3c/webcodecs/issues/270 Support per-frame QP configuration by VideoEncoder #270
- 00:04:41 [nigel]
- nigel has joined #mediawg
- 00:04:56 [dom]
- eugene: QP tends to be codec specific
- 00:05:27 [dom]
- ... the advice we're getting from people working with codecs is to not try to use a common denominator approach
- 00:05:37 [dom]
- ... they want finegrained controls to tune this
- 00:05:52 [dom]
- ... so we're working towards a codec specific approach via settings in the registry
- 00:05:58 [cpn]
- q?
- 00:06:35 [cpn]
- ack ber
- 00:06:44 [dom]
- Bernard: the cool thing about per-frame QP is that it can have an impact on congestion control
- 00:07:07 [dom]
- ... re latency mode - I've been playing with it on the video side, when I set it to "quality", it doesn't seem to make any difference in latency
- 00:07:22 [dom]
- ... and it generates fewer keyframes, which improve the transport latency
- 00:07:26 [dom]
- ... is that intended?
- 00:07:48 [dom]
- eugene: this is implementation specific, it's hard to tell without more details on the encoder
- 00:08:02 [dom]
- ... the API is not trying to be creative, it reflects the knobs from the encoder
- 00:08:21 [dom]
- ... please send me links to your code sample and I'll take a look
- 00:08:33 [dom]
- ... it's not the intended behavior
- 00:08:35 [cpn]
- q?
- 00:08:43 [Bernard]
- q-
- 00:09:32 [dom]
- Topic: Wrap up
- 00:09:42 [dom]
- CPN: who are the relevant WGs we need to coordinate with?
- 00:10:06 [dom]
- Bernard: I had missed the XR folks in my list
- 00:11:05 [cpn]
- Dom: For the architecure we need the WGs more than IGs
- 00:11:11 [kaz]
- present+ Kenaku_Komatsu
- 00:11:30 [cpn]
- ... For the media pipeline, not sure WHATWG stream is needed to be involved in the architecture
- 00:11:31 [kaz]
- i/For the/scribenick: cpn/
- 00:11:53 [cpn]
- Bernard: WHATWG streams are a black box, difficult to see how much latency is contributed
- 00:11:53 [kaz]
- rrsagent, draft minutes
- 00:11:53 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html kaz
- 00:12:21 [cpn]
- Dom: As we go through this and collaborate on code samples, some issues may need to be surfaced to WHATWG streams
- 00:12:32 [kaz]
- present+ Youenn_Fablet
- 00:12:37 [cpn]
- ... Who do we need at the table to design the pipeline?
- 00:12:58 [cpn]
- ... Suggest doing it iteratively, then convince people to contribute to it
- 00:13:06 [kaz]
- present+ Eric_Carlson
- 00:13:21 [kaz]
- present+ David_Singer
- 00:13:26 [cpn]
- ... Let's start with those already here, then when we find pieces we don't understand in depths, reach out to the relevant groups
- 00:14:07 [cpn]
- ... Workshop with several components. It's an interesting idea to run a workshop. Once we have an initial architecture, we'll know who to invite
- 00:14:24 [cpn]
- ... So suggest starting small and iterate. Once we get stuck, extend the conversation
- 00:14:59 [cpn]
- ... The real question is to find people committed to look at it. May be harder to find than people willing to work on the solutions
- 00:15:11 [cpn]
- ... Who'd be willing to drive it?
- 00:15:12 [peter]
- q+
- 00:15:22 [cpn]
- Bernard: I'm one person, but don't know all the pieces
- 00:15:32 [cpn]
- Peter: I volunteer, for the parts I know about
- 00:15:47 [cpn]
- Bernard: Would be helpful to have sample code that illustrate problem points
- 00:16:20 [cpn]
- ... We have some in WebCodecs, spend time developing samples. Particularly encourage the AR/VR people to try out WebCodecs
- 00:16:34 [cpn]
- ... What kinds of sample could would be illustrative?
- 00:17:05 [cpn]
- Dom: I think we should take the use cases and identify integration points. Some may not be possible, and what would it take to make them possible would be an outcome?
- 00:17:39 [cpn]
- ChrisN: Where to host the repo?
- 00:17:56 [cpn]
- Dom: Something like media-pipeline-architecture under w3c github
- 00:18:24 [cpn]
- Bernard: IETF have hackathons, could that be a useful thing? Does w3c do that?
- 00:18:49 [cpn]
- Dom: If we have sponsors and a time and place, it's possible. I have less experience with virtual hackathons
- 00:18:59 [cpn]
- ... Could be investigated as part of the workshop idea
- 00:19:32 [cpn]
- Cullen: An IETF hackathon could be welcome. Agree with Dom, virtual hackathons haven't been so successful compared to having people in the room
- 00:20:08 [kaz]
- q+
- 00:20:14 [cpn]
- ... Next IETF is London in October. They'd be happy if we showed up to hack there
- 00:20:20 [dom]
- ack peter
- 00:20:21 [kaz]
- ack p
- 00:20:22 [dom]
- ack kaz
- 00:20:47 [englishm]
- s/October/November/
- 00:20:56 [dom]
- kaz: Web of things wg has been holding plugfests, with @@@ to help separate remote collaboration
- 00:21:05 [kaz]
- s/@@@/SoftEther VPN/
- 00:21:14 [kaz]
- ack k
- 00:21:35 [dom]
- CPN: we've done a few ad-hob joint meetings between our 2 groups
- 00:21:45 [dom]
- ... when should we plan our next?
- 00:22:34 [cpn]
- Dom: How long would it need to do some initial work to bring to that meeting?
- 00:22:52 [cpn]
- Bernard: Depends on the topic. A month or two for sample code.
- 00:23:04 [cpn]
- Dom: So perhaps end of October
- 00:23:12 [cpn]
- Bernard: Aligns with IETF
- 00:23:20 [kaz]
- rrsagent, draft minutes
- 00:23:20 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html kaz
- 00:23:56 [Bernard]
- Bernard Aboba: Present
- 00:24:16 [Will]
- Will has joined #mediawg
- 00:24:20 [kaz]
- present+ Bernard_Aboba
- 00:24:23 [kaz]
- [adjourned]
- 00:24:24 [eric-carlson]
- present+ Eric Carlson
- 00:24:25 [kaz]
- rrsagent, draft minutes
- 00:24:25 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html kaz
- 00:24:37 [bneedham]
- bneedham has left #mediawg
- 00:32:34 [ada]
- q+
- 00:32:42 [ada]
- q=
- 00:32:44 [ada]
- q-
- 00:56:49 [nigel]
- nigel has joined #mediawg
- 01:01:17 [nigel]
- nigel has joined #mediawg
- 01:03:25 [hfujisawa]
- hfujisawa has left #mediawg
- 01:03:30 [nigel]
- nigel has joined #mediawg
- 01:11:13 [nigel_]
- nigel_ has joined #mediawg
- 02:45:31 [miseydl]
- miseydl has joined #mediawg
- 04:12:23 [Zakim]
- Zakim has left #mediawg
- 04:27:20 [eeeps]
- eeeps has joined #mediawg
- 20:58:55 [RRSAgent]
- RRSAgent has joined #mediawg
- 20:58:55 [RRSAgent]
- logging to https://www.w3.org/2022/09/16-mediawg-irc
- 20:59:01 [Zakim]
- Zakim has joined #mediawg
- 20:59:03 [nigel]
- nigel has joined #mediawg
- 20:59:08 [cpn]
- Meeting: Media WG
- 20:59:23 [cpn]
- Chair: Chris_Needham
- 21:00:04 [miseydl]
- miseydl has joined #mediawg
- 21:00:29 [miseydl_]
- miseydl_ has joined #mediawg
- 21:01:16 [Matt_Wolenetz]
- present+ Matt_Wolenetz
- 21:01:20 [cpn]
- Present+ Dan_Sanders, Hiroshi_Kajihata, Francois_Daoust, Peter_Thatcher, Eric_Carlson, Tuukka_Toivonnen
- 21:01:42 [ken]
- ken has joined #mediawg
- 21:02:03 [ken]
- +present
- 21:02:14 [tidoust]
- present+ Xiaohan_Wang, Michael_Seydl, Hiroshi_Kajihata, Greg_Freedman, Alastor_Wu
- 21:02:33 [dom]
- Present+
- 21:02:47 [eugene]
- eugene has joined #mediawg
- 21:03:22 [ken]
- present+
- 21:03:28 [gkatsev]
- present+
- 21:03:29 [padenot]
- present+
- 21:03:33 [eugene]
- present+ Eugene_Zemtsov
- 21:03:39 [tguilbert]
- tguilbert has joined #mediawg
- 21:03:44 [miseydl_]
- present+
- 21:03:47 [tguilbert]
- present+ Thomas_Guilbert
- 21:03:47 [alwu]
- present+
- 21:03:57 [Bernard_Aboba]
- Bernard_Aboba has joined #mediawg
- 21:03:58 [herre]
- present+
- 21:04:00 [youenn]
- youenn has joined #mediawg
- 21:04:06 [Chris_Lemmons]
- Chris_Lemmons has joined #mediawg
- 21:04:10 [eric-carlson]
- eric-carlson has joined #mediawg
- 21:04:27 [Chris_Lemmons]
- +Observing. :)
- 21:04:36 [eric-carlson]
- present+ Eric Carlson
- 21:04:38 [peter]
- peter has joined #mediawg
- 21:04:50 [peter]
- present+ Peter Thatcher
- 21:05:44 [plh]
- plh has joined #mediawg
- 21:06:12 [tovep]
- tovep has joined #mediawg
- 21:07:21 [jernoble]
- jernoble has joined #mediawg
- 21:07:30 [jernoble]
- present+ Jer Noble
- 21:08:15 [tovep]
- present+ Tove_Petersson
- 21:08:30 [Xiaohan_Wang]
- Xiaohan_Wang has joined #mediawg
- 21:08:46 [tidoust]
- scribe: tidoust
- 21:08:52 [dom]
- Agenda: https://www.w3.org/events/meetings/25bfcb9a-473c-48da-b44c-9bca49e39be7
- 21:08:57 [tidoust]
- Topic: Agenda bashing
- 21:09:06 [tidoust]
- cpn: [reviewing the agenda]
- 21:09:36 [tidoust]
- ... Re. WebCodecs, some follow-up to yesterday's discussion with WebRTC WG.
- 21:10:23 [tidoust]
- ... Then Autoplay Policy Detection, Media session issues and session capture and an introduction on Document Picture in Picture API.
- 21:10:31 [tidoust]
- ... Suggestions to changes/additions?
- 21:10:36 [igarashi__]
- igarashi__ has joined #mediawg
- 21:10:48 [igarashi__]
- present+ Tatsuya_Igarashi
- 21:11:36 [tidoust]
- [some discussion on switching agenda topics to accommodate early flights back]
- 21:14:26 [tidoust]
- Topic: Media WG Introduction
- 21:14:49 [tidoust]
- cpn: Mission is to develop media specifications to improve media support on the web.
- 21:15:10 [tidoust]
- ... Looking at an overview of the specs as they stand.
- 21:15:38 [tidoust]
- ... MSE v2, we're at WD. Question is then: what do we think we need to publish a CR?
- 21:16:16 [tidoust]
- ... For EME v2, we made a number of updates, but they are in an ED. I'd like to get a sense of where we are towards publishing a FPWD.
- 21:16:45 [tidoust]
- ... Media Capabilities is pretty mature. It is not on the agenda but it would be interested to understand the blockers towards publication as CR.
- 21:16:57 [dom]
- Slideset: https://lists.w3.org/Archives/Public/www-archive/2022Sep/att-0011/Media_WG_Meeting_16_Sep_2022.pdf
- 21:17:02 [dom]
- [slide 7]
- 21:17:18 [tidoust]
- ... Media Playback Quality is complete but we agreed to integrate that into HTML and we need someone who can help do that.
- 21:17:38 [tidoust]
- ... Autoplay Policy Detection was published as FPWD. We probably want to initiate horizontal reviews.
- 21:18:13 [tidoust]
- ... WebCodecs, some question on publishing the registry as a real W3C Registry now that there is such a track, instead of as a draft Note.
- 21:18:37 [tidoust]
- ... For both Media Session and Picture-in-Picture, some of these are implemented and deployed. What are the steps to progress these to CR?
- 21:19:02 [tidoust]
- ... Picture-in-Picture is more complete in its scope, Media Session more open following recent discussions on presentation actions.
- 21:19:31 [tidoust]
- Topic: Media Source Extensions v2
- 21:19:34 [dom]
- [slide 8]
- 21:19:56 [tidoust]
- Matt_Wolenetz: Approximately 20 issues to go through but we won't have time to go through all of them.
- 21:20:00 [ghurlbot]
- ghurlbot has joined #mediawg
- 21:20:07 [dom]
- Repository: w3c/media-source
- 21:20:29 [tidoust]
- ... Two goals here today: present the current status. 1) What changed since the Recommendation. 2) Get some feedback on priorities for v2.
- 21:20:53 [tidoust]
- ... If you're interested in any of these features, please reach out directly to me or through the GitHub repository, I'm interested!
- 21:21:13 [dom]
- #100
- 21:21:18 [Matt_Wolenetz]
- https://github.com/w3c/media-source/labels/TPAC-2022-discussion
- 21:21:27 [tidoust]
- ghurlbot, this is w3c/media-source
- 21:21:27 [ghurlbot]
- tidoust, OK
- 21:21:35 [dezell]
- dezell has joined #mediawg
- 21:21:36 [dom]
- #100
- 21:21:39 [ghurlbot]
- https://github.com/w3c/media-source/issues/100 -> Issue 100 Have appendBuffer and remove return promise. (jyavenard) TPAC-2022-discussion
- 21:21:41 [dezell]
- present+
- 21:22:20 [tidoust]
- Matt_Wolenetz: Since Rec, we landed one major feature: changeType. It's been used for a lot of different things. AV1/VP9 switching for instance.
- 21:22:35 [tidoust]
- ... Without user visible pauses.
- 21:22:52 [tidoust]
- ... Second feature: MSE in workers is in the specification. One question to answer today.
- 21:23:18 [tidoust]
- ... We had to unship the feature due to backward incompatibility issues with other MSE features.
- 21:23:36 [dsinger]
- dsinger has joined #mediawg
- 21:23:44 [tidoust]
- ... The issue tracker lists a number of features that could be considered for v2.
- 21:23:55 [tidoust]
- Matt_Wolenetz: Back to issue 100.
- 21:24:31 [tidoust]
- ... Have appendBuffer and remove return promise. That seems pretty obvious to me.
- 21:24:43 [tidoust]
- ... If you see blockers, speak up now or comment on the issue tracker.
- 21:24:59 [dom]
- i/Matt_/Subtopic: Issue #100
- 21:24:59 [tidoust]
- Matt_Wolenetz: Next one is #232
- 21:25:00 [ghurlbot]
- https://github.com/w3c/media-source/issues/232 -> Issue 232 Define a preemptive eviction MSE API for low-memory platforms (wolenetz) feature request, TPAC-2022-discussion
- 21:25:02 [dom]
- Subtopic: Issue #232
- 21:25:38 [tidoust]
- Matt_Wolenetz: What a conforming implementation might do with regards to picking up ranges for buffer eviction.
- 21:25:40 [nigel]
- nigel has joined #mediawg
- 21:26:21 [jernoble]
- q?
- 21:26:23 [jernoble]
- q+
- 21:26:38 [tidoust]
- ... To my knowledge, the only remaining technical blocker for getting MSE implemented on small device such as iOS is pre-emptive buffer eviction mechanism.
- 21:27:31 [tidoust]
- ... ManagedMediaSource and ManagedSourceBuffer could perhaps be used to distinguish cases with pre-emptive eviction from those without.
- 21:28:12 [cpn]
- q?
- 21:28:21 [tidoust]
- ack jernoble
- 21:28:29 [nigel]
- nigel has joined #mediawg
- 21:28:59 [tidoust]
- jernoble: I was thinking along the same lines, not necessarily about new objects but some configuration objects to switch to a different mode.
- 21:29:06 [nigel]
- nigel has joined #mediawg
- 21:29:19 [tidoust]
- ... Whether it's a completely new object or some mode, we can bikeshed a lot but that's eventually the same.
- 21:29:58 [cpn]
- q?
- 21:30:05 [tidoust]
- ... There is a little more SF concept. On iOS, they can mark certain memory as purgeable. We certainly don't want to expose memory purging to JS.
- 21:30:17 [tidoust]
- ... But we need to do something about it.
- 21:30:47 [tidoust]
- Matt_Wolenetz: To be clear, that's not only about iOS, Chrome implementation also could use some low-memory signals we get from the OS.
- 21:31:08 [tidoust]
- ... Look forward to working with you on that. That would be super for the ecosystem.
- 21:31:15 [tidoust]
- cpn: What needs to happen next?
- 21:31:45 [tidoust]
- Matt_Wolenetz: A PR would be a great starting point for a discussion on whether to use new objects or a new mode.
- 21:31:56 [tidoust]
- ... External contributions absolutely welcome on this.
- 21:32:10 [tidoust]
- Subtopic: Issue #189
- 21:32:10 [ghurlbot]
- https://github.com/w3c/media-source/issues/189 -> Issue 189 Add Support for Media-Encoded Events (tinskip) feature request, question, TPAC-2022-discussion
- 21:32:25 [cpn]
- q+
- 21:32:54 [tidoust]
- Matt_Wolenetz: Discussed extensively at last TPAC. Add support for DataCue exposure of in-band metadata in emsg boxes.
- 21:33:03 [tidoust]
- ack cpn
- 21:33:15 [tidoust]
- cpn: I think it was TPAC 2019.
- 21:33:29 [tidoust]
- ... Since then, we've been very slowly working on the DataCue API.
- 21:33:53 [nigel]
- nigel has joined #mediawg
- 21:34:01 [nigel]
- nigel has joined #mediawg
- 21:34:15 [cyril_]
- cyril_ has joined #mediawg
- 21:34:15 [tidoust]
- ... Two things: the DataCue API could be entirely separated from MSE. The current approach is to use a VTTCue but it would be good to be able to do that with any kind of cue.
- 21:34:44 [tidoust]
- ... Looking at the DataCue implementation that Webkit has, the proposal is that we standardize on that for the API shape.
- 21:34:59 [tidoust]
- ... Really, I'm looking for explicit support from implementers.
- 21:35:06 [dom]
- -> https://github.com/WICG/datacue/blob/main/explainer.md DataCue explainer
- 21:35:08 [nigel]
- nigel has joined #mediawg
- 21:35:12 [tidoust]
- ... Separated from that, there's the question of in-band events.
- 21:35:15 [cyril_]
- RRSagent, pointer
- 21:35:15 [RRSAgent]
- See https://www.w3.org/2022/09/16-mediawg-irc#T21-35-15
- 21:35:30 [dom]
- RRSAgent, draft minutes
- 21:35:30 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html dom
- 21:35:36 [tidoust]
- ... The browser could extract those and surface them to the application through DataCue.
- 21:35:48 [tidoust]
- ... There has been some collaboration with DASH-IF.
- 21:36:25 [tidoust]
- ... Constrained devices don't want to have to touch the media twice. The argument I hear is that parsing the container for metadata is not computationally expensive, so could be done through scripts.
- 21:36:50 [tidoust]
- ... For more constrained devices, the question still stands.
- 21:37:19 [nigel]
- nigel has joined #mediawg
- 21:37:29 [tidoust]
- ... Parsing and exposing through MSE could be a direction. Here as well, I'm looking for explicit support for that.
- 21:37:52 [tidoust]
- ... We don't want to figure out the details of how everything works without some initial expression of support.
- 21:38:17 [tidoust]
- Matt_Wolenetz: The Chromium implementation for even in-band text has been removed from MSE.
- 21:38:45 [tidoust]
- ... If we're going to expose in-band metadata somehow, it would certainly be some non-trivial impementation work.
- 21:39:06 [nigel]
- nigel has joined #mediawg
- 21:39:46 [tidoust]
- ... Interactions with timestamps could perhaps trigger weird behavior that need to be looked into if we integrate that in MSE.
- 21:40:47 [tidoust]
- cpn: Should I take that as a semi-positive feedback?
- 21:41:14 [tidoust]
- Matt_Wolenetz: Sure, it would be good to have external input. It would help speed up specification work.
- 21:41:22 [tidoust]
- ... External PRs would be helpful.
- 21:41:56 [tidoust]
- cpn: That's where we struggle perhaps. People in DataCue are more from the media container angle, not experts in MSE.
- 21:42:15 [cpn]
- q?
- 21:42:35 [tidoust]
- Matt_Wolenetz: If there's a bytestream format that this would be particularly tied with, people could consider looking into that first and pointing out where precisely things need to happen.
- 21:42:54 [tidoust]
- Subtopic: MSE v2 feature prioritisation and developer input
- 21:43:08 [dsinger]
- dsinger has joined #mediawg
- 21:43:09 [dom]
- #175
- 21:43:12 [ghurlbot]
- https://github.com/w3c/media-source/issues/175 -> Issue 175 MediaSource in Worker (DanielBaulig) feature request, needs follow-up, TPAC-2022-discussion
- 21:44:41 [tidoust]
- Matt_Wolenetz: One issue wasn't caught that since the main thread implementation throws when handle is not available, the MSE in worker feature introduces a backward incompatibility that affects existing products.
- 21:44:54 [tidoust]
- Gary: Old version of video.js typically
- 21:45:16 [tidoust]
- Matt_Wolenetz: 2 options: restrict that getter visibility to only the dedicated Worker context.
- 21:45:30 [tidoust]
- ... Even there we would change it to never throw an exception.
- 21:45:49 [tidoust]
- ... The alternative is to return null if it's not supported instead of throwing an exception.
- 21:45:50 [jernoble]
- q+
- 21:46:10 [nigel]
- nigel has joined #mediawg
- 21:46:22 [cpn]
- ack jer
- 21:46:24 [tidoust]
- ... We'd have to specify that through text as WebIDL does not allow that to be expressed directly.
- 21:46:43 [nigel]
- nigel has joined #mediawg
- 21:46:45 [tidoust]
- jernoble: Do we have an articulated use to be able to access the handle from the main thread?
- 21:47:03 [tidoust]
- Matt_Wolenetz: For now, no. But there is something on that table.
- 21:47:27 [dom]
- +1 to visibility instead of null
- 21:47:47 [tidoust]
- jernoble: My vote would be to do the hidden option. If we do have that use case, we can extend it afterwards.
- 21:48:01 [tidoust]
- Matt_Wolenetz: Thanks. That helps.
- 21:48:31 [gregwf]
- gregwf has joined #mediawg
- 21:48:33 [dom]
- Matt_Wolenetz: that also includes not throwing an exception
- 21:48:48 [Matt_Wolenetz]
- Next, group of issues: (#259, #209, #172, #40, #35) relating to "introspection API".
- 21:48:49 [ghurlbot]
- https://github.com/w3c/media-source/issues/35 -> Issue 35 Report buffer changes in update events (dmlap) feature request, TPAC-2022-discussion
- 21:48:49 [ghurlbot]
- https://github.com/w3c/media-source/issues/209 -> Issue 209 Expose SourceBuffer as an ArrayBuffer (guest271314) feature request, TPAC-2022-discussion
- 21:48:49 [ghurlbot]
- https://github.com/w3c/media-source/issues/259 -> Issue 259 Consider adding support for apps to get metadata about what is currently buffered (wolenetz) TPAC-2022-discussion
- 21:48:50 [Github]
- https://github.com/w3c/media-wg/issues/35 : TPAC 2022 planning
- 21:48:50 [ghurlbot]
- https://github.com/w3c/media-source/issues/172 -> Issue 172 Consider adding API for app to know how much room is left in the SourceBuffer (wolenetz) feature request, needs author input, needs follow-up, TPAC-2022-discussion
- 21:48:54 [ghurlbot]
- https://github.com/w3c/media-source/issues/40 -> Issue 40 Needs event to notify when sourceBuffer needs more data (stnishimura) feature request, TPAC-2022-discussion
- 21:49:49 [tidoust]
- Matt_Wolenetz: A group of 5 issues to come next. First on exposing SourceBuffer as an ArrayBuffer.
- 21:50:23 [tidoust]
- ... Both are related. Getting metadata.
- 21:50:43 [tidoust]
- ... Better visibility about what is still buffered.
- 21:51:01 [eric-carlson]
- eric-carlson has joined #mediawg
- 21:51:23 [tidoust]
- ... These have all received mixed expression of interest. I would like to get better and more explicit expressions of support and details on how these features would be used.
- 21:51:25 [cpn]
- q?
- 21:51:37 [Matt_Wolenetz]
- #185, #14
- 21:51:38 [ghurlbot]
- https://github.com/w3c/media-source/issues/14 -> Issue 14 Update SourceBuffer.appendStream() and related algorithms to use ReadableByteStream (wolenetz) feature request, blocked, needs follow-up, TPAC-2022-discussion
- 21:51:39 [ghurlbot]
- https://github.com/w3c/media-source/issues/185 -> Issue 185 Feature Request: Implement appendBuffer(blob) (beaufortfrancois) feature request, TPAC-2022-discussion
- 21:51:39 [Github]
- https://github.com/w3c/media-wg/pull/14 : Fix broken links in agenda doc
- 21:52:13 [tidoust]
- Matt_Wolenetz: Moving to 14, which was cut from the Rec because implementations had not caught up with the spec.
- 21:52:39 [tidoust]
- ... Maybe add a readable endpoint so that you can fetch and pipe.
- 21:52:51 [eric-carlson__]
- eric-carlson__ has joined #mediawg
- 21:53:13 [tidoust]
- cpn: I think that was one that Zach was particularly interested into.
- 21:53:21 [tidoust]
- ... We can probably get some input from him.
- 21:53:51 [tidoust]
- jernoble: You said this could help with fixing low-memory conditions. Could you expand on them?
- 21:54:46 [tidoust]
- Matt_Wolenetz: Trying to recall. Buffer eviction. Previous prototype was around cases where we provide P-frames very infrequently
- 21:55:47 [tidoust]
- jernoble: Interesting that we're contemplating giving back control to the user agent whereas the whole motivation for MSE was to take it away from it.
- 21:56:07 [tidoust]
- Matt_Wolenetz: OK, I'll follow-up with Zach from Disney on this one
- 21:56:14 [dom]
- #184
- 21:56:14 [ghurlbot]
- https://github.com/w3c/media-source/issues/184 -> Issue 184 Enable buffering of WebCodecs Encoded Chunks for playback with MSE - aka "MSE for WebCodecs" or "MSE4WC" (AndrewMD5) TPAC-2022-discussion
- 21:56:58 [tidoust]
- Matt_Wolenetz: Next one is linked to buffering WebCodecs encoded chunks for playback with MSE.
- 21:57:05 [dom]
- #302
- 21:57:05 [ghurlbot]
- https://github.com/w3c/media-source/issues/302 -> Pull Request 302 MSE-for-WebCodecs draft feature specification (wolenetz)
- 21:57:24 [tidoust]
- ... MSE for WebCodecs was in origin trial in Chromium but interest seems to be relatively low.
- 21:57:37 [cpn]
- q+
- 21:57:46 [tidoust]
- ... If you are very interested by this issue, please speak up, otherwise we'll just remove the feature.
- 21:58:24 [dom]
- ack cpn
- 21:58:28 [tidoust]
- cpn: From WebCodecs, you can receive and decode. If you want to render, you need to integrate a lot of concepts such as buffering. With this feature, would that give a way to hand things over to the user agent?
- 21:59:07 [tidoust]
- Matt_Wolenetz: I think DASH.js does transmuxing from MPEG-TS to MP4 and feeds that into MSE. That could simplify things.
- 21:59:55 [Bernard_Aboba]
- q+
- 22:00:14 [tguilbert]
- s/DASH.js/HLS.js
- 22:00:28 [dom]
- ack Bernard_Aboba
- 22:00:28 [tidoust]
- ... I didn't get enough support to create a full pipeline and see how that would improve things.
- 22:01:17 [tidoust]
- Bernard_Aboba: I actually know some customers of HLS.js that are very interesting in low latency. Would it be useful to reach out to them?
- 22:01:26 [tidoust]
- Matt_Wolenetz: Yes, it would be useful to have more active participation.
- 22:01:27 [cpn]
- q?
- 22:01:50 [tidoust]
- cpn: We're reaching the end of the allocated time.
- 22:02:27 [tidoust]
- Matt_Wolenetz: Yes, there are a bunch of them. Audio PCM support. Main thread SourceObject attachment. Long been asked for.
- 22:02:50 [tidoust]
- jernoble: Don't we already have it? I'm pretty sure we have it in Safari.
- 22:03:07 [tidoust]
- Matt_Wolenetz: You probably do, and Firefox as well I think, but it's not in the spec.
- 22:03:25 [tidoust]
- ... And then a bunch of interoperability issues, mostly around timing.
- 22:04:03 [tidoust]
- ... These are lower-complexity issues.
- 22:04:06 [dom]
- [MediaSource as a valid value for srcObject has been in HTML for quite some time IIRC https://html.spec.whatwg.org/multipage/media.html#media-provider-object ]
- 22:04:35 [tidoust]
- cpn: Live stream and playback through unbuffered ranges is something we're interested in at BBC.
- 22:04:52 [tidoust]
- ... For those interoperability, we can schedule a future call and go through those.
- 22:06:36 [tidoust]
- Topic: Media Session
- 22:06:41 [dom]
- ghurlbot, this is https://github.com/w3c/mediasession
- 22:06:41 [ghurlbot]
- dom, OK
- 22:06:44 [dom]
- [slide 14]
- 22:07:00 [tidoust]
- #274
- 22:07:01 [ghurlbot]
- https://github.com/w3c/mediasession/issues/274 -> Issue 274 [closed] Should we add slide presentation specific actions? (youennf)
- 22:07:05 [dom]
- Subtopic: Media Session & WebRTC
- 22:07:42 [dom]
- #284
- 22:07:43 [ghurlbot]
- https://github.com/w3c/mediasession/issues/284 -> Pull Request 284 [closed] Add presenting slides actions (beaufortfrancois)
- 22:07:55 [eugene_]
- eugene_ has joined #mediawg
- 22:08:07 [tidoust]
- cpn: We had a call with Media Session editors and WebRTC folks to add slide presentation specific actions. We got agreement to add support for them in Media Session.
- 22:08:14 [tidoust]
- youenn: PR merged this morning.
- 22:08:29 [dom]
- -> https://w3c.github.io/mediacapture-handle/actions/ The Capture-Handle Actions Mechanism
- 22:08:30 [tidoust]
- ... Next step is implementation. Other part is reusing in Media Capture Actions.
- 22:09:06 [tidoust]
- ... This work should probably be tackled within the WebRTC WG since it owns the Media Capture Handle Actions.
- 22:09:19 [cpn]
- q+ elad
- 22:09:20 [tidoust]
- cpn: Media Session only defines the action ids?
- 22:09:23 [tidoust]
- youenn: yes.
- 22:09:26 [dom]
- ack elad
- 22:09:27 [cpn]
- ack elad
- 22:09:52 [tidoust]
- elad: More things will be needed. Right now, if you get the event, you don't know whether it got delivered by the user or by a presentation.
- 22:10:01 [tidoust]
- ... You don't know what the user intended.
- 22:10:30 [tidoust]
- ... That's ok provided the application that receives these events is willing to treat them regardless of where they were issued.
- 22:10:40 [tidoust]
- ... I think something needs to be added.
- 22:11:06 [tidoust]
- youenn: Yes, but that's still very early and indeed the security model needs to be defined for media capture actions first.
- 22:11:11 [dom]
- #285
- 22:11:12 [ghurlbot]
- https://github.com/w3c/mediasession/issues/285 -> Issue 285 The active media session might not be the only one being notified of actions (youennf)
- 22:11:13 [eugene]
- eugene has joined #mediawg
- 22:11:55 [tidoust]
- youenn: This discussion led us to next issue. There are cases where the media session is not active but you still want to send the actions.
- 22:12:17 [tidoust]
- ... A page still needs to be notified.
- 22:12:24 [dom]
- #287
- 22:12:25 [ghurlbot]
- https://github.com/w3c/mediasession/issues/287 -> Pull Request 287 Introduce the possibility for a source to be tied to a specific media session (youennf)
- 22:12:45 [tidoust]
- ... If the source is not tied to a particular media session, we may want to associate it with an active one,
- 22:13:01 [tidoust]
- ... The PR is available. I don't think it has been reviewed yet.
- 22:13:27 [tidoust]
- Tommy_Steimel: Just to be clear, it does not change the actual API, right?
- 22:13:34 [tidoust]
- youenn: That's correct.
- 22:13:40 [tidoust]
- ... No implementation change.
- 22:14:09 [tidoust]
- Subtopic: Status of AudioFocus API #277
- 22:14:09 [ghurlbot]
- https://github.com/w3c/mediasession/issues/277 -> Issue 277 Status of AudioFocus API (chrisn)
- 22:14:40 [cpn]
- q?
- 22:14:54 [tidoust]
- cpn: I noticed that if we define more precisely AudioFocus, we can define more precisely what happens in media session.
- 22:15:34 [tidoust]
- youenn: It's a good idea. We should spend time on that. I know that we have some user experiences which are not great. E.g. in iOS when you're mixing audio and microphone for instance.
- 22:16:03 [tidoust]
- ... AudioFocus would allow to tune the user experience. I'm hoping that I'm not alone here and that other implementers are interested.
- 22:16:14 [padenot]
- q+
- 22:16:19 [dom]
- -> https://github.com/WICG/audio-focus/blob/main/explainer.md AudioFocus API Explainer
- 22:16:20 [tidoust]
- Tommy_Steimel: Specifically with Media Session or AudioFocus as standalone?
- 22:16:54 [tidoust]
- youenn: The fact that you're suspended and when it happens in iOS would be very cool. It could be tied to Media Session. But just on its own, it's good as well.
- 22:18:13 [tidoust]
- ... On iOS, only one application is able to run audio. If a page plays audio and you e.g. switch to Youtube, audio will stop. But the app does not know it got suspended.
- 22:18:26 [tidoust]
- ... So it won't know whether it can resume either.
- 22:18:49 [tidoust]
- ... It would also allow you to specify applications that can blend well with other applications.
- 22:19:35 [tidoust]
- eric-carlson: An example. "I play audio that's fine to mix with others". If you play file based audio, we assume that it cannot be mixed with others.
- 22:20:01 [tidoust]
- ... Whereas you may have an app that plays an MP3 audio file when an event occurs and it will interrupt the audio.
- 22:21:00 [tidoust]
- padenot: Are we going to send notifications to say something else is attempting to play? Or are we going to fire an event to say you've been interrupted?
- 22:21:11 [cpn]
- q?
- 22:21:15 [cpn]
- ack pa
- 22:21:24 [tidoust]
- eric-carlson: That happens at a lower level, we cannot interrupt that.
- 22:22:02 [tidoust]
- padenot: I'm trying to remember why previous proposal stalled.
- 22:22:40 [tidoust]
- ... Regardless of the technicalities, I would also like to have something like this on the platform.
- 22:23:16 [tidoust]
- youenn: Also a problem with audio level on iOS. Mike level is different from audio level. No way for the browser to know which level to use.
- 22:23:44 [tidoust]
- elad: Is this purely specific to iOS?
- 22:23:52 [tidoust]
- youenn: Also on MacOS.
- 22:23:58 [tidoust]
- elad: What about Windows?
- 22:24:05 [tidoust]
- [not sure]
- 22:24:26 [cpn]
- scribe+ cpn
- 22:24:28 [tidoust]
- Tommy_Steimel: We do some amount of something similar to the AudioFocus API internally.
- 22:24:32 [dom]
- s/[not sure]/Paul: there is something equivalent on android and windows
- 22:25:02 [tidoust]
- ... I don't know of definitive use cases in Chrome that would make use of it.
- 22:25:29 [tidoust]
- cpn: It seems that we're looking for someone who could pick up the explainer and progress that.
- 22:25:50 [tidoust]
- youenn: I have limited time but willing to look into it. At some point, it was part of the Media Session specification.
- 22:26:02 [tidoust]
- ... I can understand why it was there in the first place.
- 22:26:07 [padenot]
- e.g. Windows, https://docs.microsoft.com/en-us/windows/win32/coreaudio/stream-attenuation
- 22:26:45 [tidoust]
- ... If it's less premature, it could perhaps be worth re-introducing it in the spec.
- 22:28:03 [dom]
- -> https://www.w3.org/2021/07/media-wg-charter.html#potential-normative Potential Normative Specifications, includes "Audio Focus API"
- 22:29:20 [tidoust]
- [group looking at charter, audio focus is a "potential normative specification" so no problem adopting it in the group if it is believed it is sufficiently mature]
- 22:29:53 [dom]
- Subtopic: Media Session and Web Audio
- 22:29:54 [tidoust]
- Subtopic: Media Session and Web Audio
- 22:30:07 [tidoust]
- #244
- 22:30:08 [ghurlbot]
- https://github.com/w3c/mediasession/issues/244 -> Issue 244 Work without an <audio> element (AshotN)
- 22:30:33 [tidoust]
- #213
- 22:30:33 [ghurlbot]
- https://github.com/w3c/mediasession/issues/213 -> Issue 213 Does media session work with WebAudio? (mmontag)
- 22:31:08 [tidoust]
- cpn: Does that suggest that Audio Focus is the next piece before we dive into relationship with Web Audio API?
- 22:31:18 [cpn]
- q?
- 22:31:46 [tidoust]
- jernoble: I agree with Mounir. If you begin playback Web Audio, it does not interrupt other audio. It was meant for game sounds, etc.
- 22:32:59 [tidoust]
- ... But common ways that user interacts with the device are not properly routed. We need some ways to indicate that the AudioContext should be considered and be able to receive controls.
- 22:33:15 [tidoust]
- youenn: Yes, I agree, also for video conferencing.
- 22:33:54 [tidoust]
- jernoble: This is a good example of an interaction where the presence of Audio Focus would make the experience better.
- 22:34:11 [tidoust]
- padenot: We really need that. It's been the case for super long.
- 22:34:39 [Matt_Wolenetz]
- s/Maybe add a readable endpoint so that you can fetch and pipe./Maybe add a writable endpoint to a SourceBuffer so that you can fetch and pipe to it./
- 22:35:26 [tidoust]
- Tommy_Steimel: Proposed solution would be to have the Audio Focus and web apps could then use the API to tell the OS about the type of audio mode they're in and get feedback from the OS?
- 22:35:32 [tidoust]
- jernoble: That's correct.
- 22:36:17 [tidoust]
- RRSAgent, draft mintes
- 22:36:17 [RRSAgent]
- I'm logging. I don't understand 'draft mintes', tidoust. Try /msg RRSAgent help
- 22:36:22 [tidoust]
- RRSAgent, draft minutes
- 22:36:22 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html tidoust
- 23:02:05 [dom]
- scribe+
- 23:02:10 [ken]
- ken has joined #mediawg
- 23:02:24 [dom]
- Topic: Encrypted Media Extensions
- 23:02:37 [dom]
- ghurlbot, this is w3c/encrypted-media
- 23:02:37 [ghurlbot]
- dom, OK
- 23:02:46 [dom]
- [slide 9]
- 23:03:02 [dom]
- cpn: the charter has limited scope for additions to EME
- 23:03:17 [dom]
- ... that includes HDCP Policy Detection, for which there is a WICG incubation
- 23:03:29 [dom]
- ... the TAG review refers to implementations in FF and in Chrome
- 23:03:53 [dom]
- ... has it been folded in EME at this point?
- 23:04:10 [dom]
- Joey: the EME spec hasn't changed in the past 12 months
- 23:04:15 [dom]
- ... no update on this in particular
- 23:04:29 [dom]
- ... I can go through the issues offline
- 23:04:39 [wseltzer]
- wseltzer has joined #mediawg
- 23:04:44 [dom]
- ... it is implemented and in use
- 23:04:47 [tguilbert]
- tguilbert has joined #mediawg
- 23:04:55 [dom]
- cpn: that would be good
- 23:05:06 [dom]
- ... our charter renewal is coming up in May next year
- 23:05:26 [dom]
- ... it would be good to show some progress as we go through rechartering
- 23:05:31 [eugene]
- eugene has joined #mediawg
- 23:06:10 [dom]
- joey: sounds reasonable; I'll try to free time in the next couple of quarters for this
- 23:06:24 [dom]
- ... I'm no longer part of the Chrome org at Google
- 23:06:37 [dom]
- cpn: are you still able to do this or should we find someone else?
- 23:06:51 [dom]
- Joey: I'm committed to do this; also happy to get help (and have been getting help)
- 23:07:09 [dom]
- ... my new team understands that I4m committed to that
- 23:07:24 [dom]
- Greg: I can also take the lead on merging HDCP from WICG to W3C
- 23:07:31 [dom]
- Joey: that'd be fantastic
- 23:07:49 [dom]
- Greg: my question to the chairs - I can create a PR for that, for which there will be comments
- 23:08:03 [dom]
- ... but what about moving the new version to FPWD
- 23:08:05 [dom]
- ... or should we wait?
- 23:08:25 [dom]
- cpn: what's in the current draft?
- 23:08:44 [dom]
- Joey: the encryption scheme capability has been added to the draft and is implemented in Chrome
- 23:08:54 [dom]
- cpn: FPWD triggers horizontal review
- 23:09:08 [dom]
- ... having more of the features in helps for that
- 23:09:27 [tidoust]
- dom: FPWD also triggers call for exclusions
- 23:09:28 [cpn]
- Dom: FPWD also triggers a call for exclusions for IPR
- 23:09:39 [Chris_Lemmons]
- Chris_Lemmons has joined #mediawg
- 23:09:54 [tidoust]
- s/dom: FPWD also triggers call for exclusions//
- 23:09:56 [dom]
- cpn: so we could land these 2 features and use this as a criteria to launch our FPWD
- 23:10:16 [dom]
- cpn: third issue is avoiding duplication sessions within the same origin
- 23:10:42 [dom]
- joey: you don't necessarily want to do the work of parsing the init data for EME to figure out what's in it
- 23:10:51 [dom]
- ... when you're going to hand it off to a more efficient c++ system
- 23:11:02 [dom]
- ... but you do want to avoid a bunch of duplicate sessions
- 23:11:26 [dom]
- ... e.g. in widevine, unless you parse the data, the player can't know this will end up creation sessions with the same keys
- 23:11:44 [dom]
- ... #467 provided a solution to ask a browser for potential key ids
- 23:11:44 [ghurlbot]
- https://github.com/w3c/encrypted-media/issues/467 -> Issue 467 API to find existing sessions (mounirlamouri) feature request
- 23:11:59 [dom]
- joey: there are situations with legacy cases where you wouldn't be able to get that data
- 23:12:17 [dom]
- ... I'm not sure what would be available from playready and fairplay, but assumes it would be available
- 23:12:35 [dom]
- ... Another approach would for the app to provide its data and ask if there is an existing matching session
- 23:12:43 [dom]
- ... we went back and forth between the two approaches
- 23:13:08 [dom]
- ... the last discussion we had about this was that "find a session by init data" was distasteful to some
- 23:13:20 [dom]
- ... but looking for confirmation / new input on this
- 23:13:28 [dom]
- ... The explainer has also additional alternatives
- 23:13:44 [dom]
- Greg: another id would to add key ids to the encrypted event
- 23:14:00 [dom]
- joey: that wouldn't work in case you get a @@@ box out of a @@@1 file
- 23:14:00 [ghurlbot]
- https://github.com/1 -> @1
- 23:14:17 [dom]
- Xiaohan: not trivial to figure key ids out of init data
- 23:14:26 [dom]
- -> https://github.com/joeyparrish/encrypted-media-find-session/blob/draft/explainer.md Finding Existing Sessions in EME Explainer
- 23:14:45 [dom]
- s/@@@/PSSH/
- 23:15:05 [dom]
- joey: I think the data is there now; it seems like something the CDM should provide info for
- 23:15:15 [dom]
- ... better than a PSSH parser in JS
- 23:15:25 [dom]
- RRSAgent, draft minutes
- 23:15:25 [RRSAgent]
- I have made the request to generate https://www.w3.org/2022/09/16-mediawg-minutes.html dom
- 23:15:49 [dom]
- Greg: going back to media-encrypted event exposing key ids
- 23:16:03 [dom]
- ... media status exposing key ids feels odd
- 23:16:19 [dom]
- ... the media-encrypted event could be correlated with key status
- 23:16:33 [dom]
- Joey: if it's available in the PSSH, it could be exposed through a method or through the mediaencrypted event
- 23:16:48 [dom]
- ... but when you get a license back, you definitely have @@@2
- 23:16:48 [ghurlbot]
- https://github.com/2 -> @2
- 23:17:39 [dom]
- Joey: they come back in key status because that's the time they're guaranteed to be available
- 23:18:06 [dom]
- ... it may not be guaranteed in init data, but it's likely they would be which would help players (which could still fallback to current workflowà
- 23:18:19 [dom]
- Xiaohan: one issue is that these init data are proprietary
- 23:18:25 [dom]
- ... but they would need to be parsed by the CDM
- 23:18:46 [dom]
- ... the encrypted eveent is fired by the demuxer
- 23:18:54 [dom]
- ... this would require hooking them to the CDM
- 23:19:38 [dom]
- Joey: in any case, the event approach wouldn't be sufficient given how often you get the PSSH data out of band
- 23:20:02 [dom]
- ... any blocker on the widevine side to add a method to the mediakey to list key ids based on init data
- 23:20:06 [dom]
- ... or what sessions match that init data
- 23:20:13 [dom]
- Xiaohan: the former is probably easier
- 23:20:23 [dom]
- ... for widevine there is also the legacy contentId
- 23:20:39 [dom]
- Joey: I would be happy to have a method that might return "no info available" in some situations
- 23:20:44 [dom]
- ... that's the existing situation
- 23:20:55 [dom]
- Xiaohan_Wang: so you really need a PSSH parser
- 23:21:06 [dom]
- Joey: yes to return the list of key ids if they're available
- 23:21:18 [dom]
- Xiaohan_Wang: the implementation would be easy, but how does it solve the problem?
- 23:21:36 [dom]
- ... e.g. how to deal with situations where expiration times are different
- 23:21:47 [dom]
- Joey: nothing is stopping the player to have overlapping sessions
- 23:21:51 [dsinger]
- dsinger has joined #mediawg
- 23:21:52 [dom]
- ... it allows avoiding them if they wish
- 23:21:56 [cpn]
- q?
- 23:22:21 [dom]
- cpn: are we saying that the explainer example is close to the direction we want to go?
- 23:22:40 [dom]
- joey: the two different options are returning a session, or return key ids and let the player figure out the right approach
- 23:22:49 [dom]
- ... I hear key ids is a bit simpler, and would suffice for my use case
- 23:23:06 [dom]
- .... that would mean dropping this explainer and proposing something else closer to #467
- 23:23:07 [ghurlbot]
- https://github.com/w3c/encrypted-media/issues/467 -> Issue 467 API to find existing sessions (mounirlamouri) feature request
- 23:24:19 [dom]
- Bernard: I can find out re MS impl
- 23:24:27 [dom]
- Jer: likewise for Apple
- 23:25:27 [dom]
- Joey: widevine still uses contentid but also lists key ids
- 23:25:58 [cpn]
- q?
- 23:28:00 [dom]
- [slide 10]
- 23:28:11 [dom]
- #499
- 23:28:12 [ghurlbot]
- https://github.com/w3c/encrypted-media/issues/499 -> Issue 499 Revisit the requirement to continuously run the "Monitor for CDM State Changes" algorithm (xhwang-chromium)
- 23:28:28 [dom]
- Xiaohan_Wang: the CDM is required to periodically check the status of the key
- 23:28:54 [dom]
- ... even when the CDM is not in use (e.g. tab is in background, not playing)
- 23:29:06 [dom]
- ... it's bad for complexity and for user's battery life
- 23:29:14 [dom]
- ... they're 2 cases that the key status can change:
- 23:29:32 [dom]
- ... - from the CDM itself - e.G. a policy that the key expires after an hour
- 23:29:53 [dom]
- ... - the key cannot be used e.G. outside of HTTPs - outside of the control of the CDM
- 23:30:09 [dom]
- ... The first one can be done through a timer without regular polling
- 23:30:12 [dom]
- s/HTTPs/HDCP
- 23:30:33 [dom]
- ... For the latter, if there is no activity, there probably isn't much value in polling
- 23:30:39 [dom]
- ... while it remains useful when decrypting
- 23:30:57 [dom]
- ... THis is related to the HDCP detection policy, the JS could use that API to poll
- 23:31:24 [dom]
- Joey: it seems to me that nobody is married to having a timer per se so long as updates are sent whenever they're useful to the app
- 23:31:51 [dom]
- ... maybe we could define the events that one would care about, then we no longer need to require regular polling
- 23:32:12 [dom]
- Greg: the initialization phase is really important, and I wouldn't want that to depend on timers
- 23:32:24 [dom]
- ... beyond that, I think it would be displayoutchange and expiration timer
- 23:32:32 [dom]
- ... any other event that may affect the key status?
- 23:32:39 [dom]
- Xiaohan_Wang: essentially yes
- 23:32:59 [dom]
- s/outchange/outputchange/
- 23:33:51 [dom]
- Xiaohan_Wang: in Chromium, the CDM is running in a sandbox with limited capabilities
- 23:34:02 [dom]
- ... I'm not sure it can detect the output change
- 23:34:11 [dom]
- ... the browser could detect it, notify the CDM which could then do that
- 23:34:24 [dom]
- ... maybe doable then, but not trivial
- 23:35:59 [dom]
- Greg: let's you're plugged into a display, there is an HDCP change, do you change the key status?
- 23:36:09 [dom]
- Xiaohan_Wang: we would not change the key status
- 23:36:23 [dom]
- ... but when the user hits play, the CDM will check everything include HDCP status
- 23:36:29 [dom]
- ... at that time, it may update the key status
- 23:36:43 [dom]
- ... it could also refuse to play if the HDCP is not good enough
- 23:36:50 [dom]
- ... Would that be too late a signal?
- 23:37:06 [dom]
- Greg: when there are display changes, we pause the video element automatically
- 23:37:13 [dom]
- ... checking the key status at that time would be good
- 23:37:45 [dom]
- Joey: but Xiaohan_Wang you're saying that may not be feasible from the sandbox?
- 23:38:02 [dom]
- Xiaohan_Wang: yes
- 23:38:11 [dom]
- ... the chromium browser definitely knows about display changes
- 23:38:19 [dom]
- ... but not sure if it would work in a sandbox context
- 23:38:33 [dom]
- ... and whether it would work across platforms (since these detections tend to be platform specific)
- 23:38:52 [dom]
- cpn: so I'm hearing we want to do this, but we're not sure about feasibility which requires a bit of investigation to be done
- 23:39:09 [dom]
- Xiaohan_Wang: +1 - we can do some investigation to come up with a more realistic proposal
- 23:40:23 [dom]
- cpn: if we can get some of this specified to get a FPWD ahead of our rechartering, that would be helpeful
- 23:40:32 [dom]
- joey: I'll make that a goal
- 23:40:34 [dom]
- Greg: so will I
- 23:40:40 [dom]
- Topic: WebCodecs
- 23:40:45 [dom]
- [slide 12]
- 23:41:12 [dom]
- cpn: did we cover everything at the joint meeting with WebRTC yesterday?
- 23:41:34 [dom]
- -> https://www.w3.org/2022/09/15-mediawg-minutes.html – DRAFT –
- 23:41:34 [dom]
- Web Real-Time Communications Working Group and Media Working Group and Media and Entertainment Interest Group - Joint meeting
- 23:41:43 [dom]
- ghurlbot, this is w3c/webcodecs
- 23:41:43 [ghurlbot]
- dom, OK
- 23:41:53 [dom]
- cpn: re #270, you were suggesting a per-codec approach?
- 23:41:53 [cpn]
- https://github.com/w3c/webcodecs/issues/270
- 23:41:54 [ghurlbot]
- https://github.com/w3c/webcodecs/issues/270 -> Issue 270 Support per-frame QP configuration by VideoEncoder (daijh) extension, TPAC 2022
- 23:42:13 [dom]
- eugene: yes, QP are codec specific, and not all encoders provide this feature
- 23:42:35 [dom]
- ... we would like to start with a prototype to check that this can provide useful control
- 23:42:43 [Bernard_Aboba]
- q+
- 23:42:50 [dom]
- ... until then, we can discuss the API shape, but it doesn't seem critical
- 23:43:01 [dom]
- ... I would like to start with prototypes for AVC and AV1
- 23:43:17 [dom]
- Bernard: it might be useful to go over the resolutions in the issue themselves
- 23:43:23 [dom]
- ... QP having different ranges across codecs
- 23:43:31 [dom]
- ... there were other questions that emerged in the API design
- 23:43:37 [dom]
- ack Bernard_Aboba
- 23:43:51 [dom]
- eugene: we're not settled on all of them
- 23:44:15 [dom]
- ... if we do it by codec in the register, if it's per-frame, we provide an extra argument to the encoder encode call
- 23:44:24 [dom]
- ... how would API users that they can provide this
- 23:44:36 [dom]
- ... isConfigSupported is only useful for testing configs
- 23:44:48 [dom]
- ... this wouldn't be via config, but an extra argument to the encode call
- 23:44:53 [dom]
- ... we haven't looked at that yet
- 23:45:33 [dom]
- ... the VideoEncoderConfig could add a special mode
- 23:45:50 [dom]
- ... First priority is prototyping
- 23:46:33 [dom]
- tguilbert: there is a PR in progress for #317
- 23:46:34 [ghurlbot]
- https://github.com/w3c/webcodecs/issues/317 -> Issue 317 [closed] Are `AudioDecoderConfig.{sampleRate,channelCount}` always required, sometimes ignored, moved to the registry ? (padenot) breaking
- 23:47:31 [dom]
- #559
- 23:47:32 [ghurlbot]
- https://github.com/w3c/webcodecs/issues/559 -> Pull Request 559 Introduce VideoFrame metadata (youennf)
- 23:48:03 [dom]
- s/317/371
- 23:48:04 [dom]
- #371
- 23:48:04 [ghurlbot]
- https://github.com/w3c/webcodecs/issues/371 -> Issue 371 AudioEncoderConfig.latencyMode (or similar) (chcunningham) extension, TPAC 2022
- 23:48:24 [dom]
- #551
- 23:48:25 [ghurlbot]
- https://github.com/w3c/webcodecs/issues/551 -> Pull Request 551 Add frameDuration attribute to OpusEncoderConfig (bdrtc)
- 23:48:36 [dom]
- Bernard: for Opus, we would do complexity, dtx and fec
- 23:48:44 [dom]
- ... this would be essentially the ptime
- 23:49:06 [dom]
- ... ptime is usually expressed in ms
- 23:49:48 [dom]
- <dom> [re milliseconds, see also -> https://w3ctag.github.io/design-principles/#milliseconds 8.3. Use milliseconds for time measurement ]
- 23:49:55 [dom]
- Subtopic: registry for webcodecs
- 23:49:59 [dom]
- #398
- 23:49:59 [ghurlbot]
- https://github.com/w3c/webcodecs/issues/398 -> Issue 398 Moving codec registry to "Registry Track" (chcunningham) editorial
- 23:50:17 [dom]
- cpn: with the registry track now available, what should be our steps in terms of moving to the registry track?
- 23:50:35 [dom]
- francois: we would need a resolution from the group to do that; it's a good fit for the document we have
- 23:50:56 [dom]
- ... the Director recommended we look into that when we published a recent registration
- 23:51:02 [dom]
- -> https://www.w3.org/2021/Process-20211102/#registries W3C Registry Track
- 23:51:15 [dom]
- francois: this would be for the registry document itself
- 23:51:27 [dom]
- ... the registration themselves would remain in draft notes
- 23:51:35 [dom]
- ... this would have much impact on the document
- 23:51:48 [dom]
- ... it mostly adds a review step to a process
- 23:51:58 [dom]
- cpn: we're already running CfC to add registrations
- 23:52:11 [dom]
- ... does that impose additional requirements beyond that?
- 23:52:22 [dom]
- francois: the registry document needs to document the process to add registration
- 23:52:29 [dom]
- ... our document is already aligned with these provisions
- 23:52:41 [dom]
- ... I can double check tbis is so
- 23:52:53 [dom]
- cpn: so it's only a mechanical step
- 23:53:05 [dom]
- ... should we run a CfC for this?
- 23:53:11 [dom]
- francois: yes
- 23:53:33 [cpn]
- PROPOSED_RESOLUTION: The WG will move the WebCodecs registry to the W3C Registry Track
- 23:55:00 [cpn]
- RESOLVED: The WG will move the WebCodecs registry to the W3C Registry Track
- 23:55:18 [dom]
- cpn: in terms of doing the update - will you take care of this francois?
- 23:55:28 [dom]
- francois: I will
- 23:55:44 [dom]
- ... and get back to group as needed
- 23:56:03 [dom]
- Subtopic: status check
- 23:56:19 [dom]
- cpn: where are we? what are the points that you are seeking input on?
- 23:56:32 [dom]
- danS: Chrome shipped webcodecs to production
- 23:56:42 [Bernard_Aboba]
- q+
- 23:56:46 [cpn]
- scribe+ cpn
- 23:56:59 [dom]
- ... we've been waiting for new browser to catch up, with a few additions in the meantime (svc, new codecs)
- 23:57:09 [dom]
- ... next thing is metadata for color gamut
- 23:57:13 [dom]
- ... see #384
- 23:57:14 [ghurlbot]
- https://github.com/w3c/webcodecs/issues/384 -> Issue 384 HDR support (ZmGorynych) extension, p1
- 23:57:29 [dom]
- ... most of the questions are about integration
- 23:57:36 [dom]
- ... e.g. with WebGPU for zero-copy
- 23:57:50 [dom]
- ... HDR & integration with CSS Color 4 and HDR Canvas
- 23:58:10 [dom]
- tguilbert: there were talks about Web Containers, everything mux/demux is done in JS
- 23:58:29 [dom]
- ... we could look into this
- 23:58:43 [dom]
- DanS: that's indeed one of the most frequest requests
- 23:59:06 [dom]
- ... this is showing a gap - the library ecosystem hasn't provided a popular solution to this yet
- 23:59:24 [dom]
- cpn: is this something you're waiting for other impl to catch up before doing that?
- 23:59:34 [dom]
- DanS: our real hope is for this to be done via JS libraries
- 23:59:51 [dom]
- ... but if event with these libraries the demand keep up, adding something outside of WebCOdecs may make sense