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