16:02:07 <RRSAgent> RRSAgent has joined #mediawg
16:02:11 <RRSAgent> logging to https://www.w3.org/2026/09/03-mediawg-irc
16:02:11 <dalecurtis> dalecurtis has joined #mediawg
16:02:17 <Zakim> Zakim has joined #mediawg
16:02:21 <cpn> Meeting: Media WG
16:02:30 <cpn> Chair: Chris, Alastor
16:02:39 <tguilbert> tguilbert has joined #mediawg
16:02:54 <cpn> Present: Dale Curtis, Thomas Guilbert, Youenn Fablet, Francois Daoust, Alastor Wu
16:03:01 <tidoust> RRSAgent, make logs public
16:03:21 <cpn> present+ Eugene Zemtzov
16:03:30 <cpn> Topic: WebCodecs issue #940
16:03:52 <cpn> Youenn: There's inconsistency between implementations on colorspace when configurin the video decoder
16:04:14 <cpn> ... When  a page provides a colorspace where some members are undefined, e.g., primaries or transfer function, what happens?
16:04:28 <cpn> ... Safari tries to merge. If unavailable, it looks to the bitstream and merges the properties
16:04:51 <cpn> ... Chrome doesn't do that, I think, but if the config isn't fully define, it's ignored somehow. Not sure about Firefox
16:05:11 <cpn> ... First, let's validate where implemantations are doing, then we can converge
16:05:40 <cpn> Dale: Chromium isn't overriding based on the config colorspace. One wrinke I realised, that on many platforms we have do decode things not  the same colorspace
16:06:06 <cpn> ... In those cases maybe want to do the same as with the null format, i.e, drop the colorspace entirely on the emitted video frame
16:06:13 <cpn> ... I'm happy to converge on behaviour
16:06:44 <cpn> ... We tried merging the dictionaries. Some are partially in the header, some in the bitstream, so not consistent
16:06:59 <cpn> ... For media we've tried that before, and it failed ... you end up with two sets of problems
16:07:27 <cpn> Youenn: If the primaries and colorspace don't match, what should we do? expose to the web, or only apply at rendering time?
16:07:43 <cpn> ... Merging, you might have a fully defined colorspace but it's invalid
16:07:46 <tidoust> present+ Iris Zhou, Paul Adenot, Chris Needham
16:08:12 <cpn> Dale: If you merge, you have two valid colorspaces: one in the bitstream, one in config. Which to choose?
16:08:24 <cpn> Youenn: In webkit we don't try to detect that, just merging
16:09:01 <cpn> ... If invalid and difficult it's to handle at rendering
16:09:07 <cpn> ... The config primes what's in the bitstream
16:09:43 <cpn> Paul: Re what firefox does, it's sketchy, esp with HDR
16:10:07 <cpn> ... When you test every platform, there are complications. In general I care more about it being well define in the standard
16:10:18 <cpn> ... If you are doing override, maybe you're controlling the bitstream
16:10:32 <cpn> ... In professional applications, I mean, where you might do somethign less standard, for good reasons
16:10:58 <cpn> Dale: My view is similar, want it to be well defined. WebCodecs always tries to follow the principle of least surprise. Merging is a bit surprising
16:11:09 <cpn> ... So when there's something partially valid, it would follow to treat as invalid
16:11:56 <cpn> Paul: There are a few places in the standard, there are ways to fall back to colorspaces that are well defined. I think that's sensible. E.g., BT709, would be a well defined guess that's unsurprising
16:12:07 <cpn> ... If more debatable, we should avoid
16:12:34 <cpn> Youenn: On the encoder side, you could always provide a fully valid colorspace. I don't think we require that yet?
16:12:48 <cpn> Dale: None might be given to us, that we'd pass through
16:12:56 <cpn> ... In Chrome only a fully specified colorspace is valid
16:13:10 <cpn> Youenn: So we could validate it in the spec, as mandatory
16:13:31 <cpn> ... For decoding, there are ways to fall back to well defined colorspaces. What standard are you referring to?
16:13:45 <cpn> Paul: Valid output config after encode is already in the spec
16:14:05 <cpn> Dale: All codec strings have defaults of BT7.09. HEVC should have that do, but not sure what the spec says
16:14:43 <cpn> Paul: In the Peak colorspace algorithm, it says "otherwise return Rec709". Sensible, if you find RGB pixels in the buffer
16:15:05 <cpn> ... When we say that, we mention the set of primaries and transfer, and fall back all four items at once
16:15:47 <cpn> Dale: Do you oppose language such as: if the config colorspace is always fully specified use it. [...] Or fall back to the [...]
16:16:29 <cpn> Youenn: But that doesn't solve the case that it's fully specified but invalid colorspace. Fall back to ignore it?
16:17:02 <cpn> ... So you specify all members, but they're not compatible with each other. For example, BT709 defines a transfer function, but some might not be compatible with it
16:17:12 <cpn> Paul: That's not very common
16:17:31 <cpn> Dale: Might be, could be BT709 with BT601
16:18:14 <cpn> ... I think it's a special case of the decoder choosing some thing else: Use fully specified codec string if you can, otherwise look at the bitstream, otherwise choose a special colorspace string if your decoder has paarticular requirements
16:18:45 <cpn> Youenn: So it's discoverable by the web app. Don't know if there are interop issues. But we can discover those as we go
16:19:02 <cpn> Dale: [...] swapping out the colorspace
16:19:27 <cpn> Youenn: So ideally, we'd need to reject if the colorspace isn't fully defined but it's there. But as we've shipped it, to avoid a breaking change, ignore it
16:20:14 <cpn> ... All members are optional, currently
16:20:45 <cpn> Dale: Changing the IDL probably not possible at this point. I thought we want if specified, you include all the fields, but that might not be possible
16:21:05 <cpn> ... I can write up next steps, what I've just described. SOunds reasonable?
16:21:31 <cpn> Youenn: Yes, seems ok. File a PR and we can test. And we'd have to change the Webkit implementation, shuoldn't be too difficult.
16:21:39 <cpn> Dale: I'll aim to write up today for review.
16:23:20 <cpn> Topic: AudioDecoderConfig with Opus, Issue 826
16:23:36 <alwu> alwu has joined #mediawg
16:23:37 <tidoust> -> https://github.com/w3c/webcodecs/issues/826 Require AudioDecoderConfig.description for channels > 2 with Opus?
16:23:39 <cpn> Thomas: This issue came up through a Chromium bug report
16:24:00 <cpn> .... It doesn't configure, check isConfigSupported first
16:24:15 <cpn> ... Opus with more than 2 channels requires a description, and FLAC requires a description
16:24:36 <cpn> ... Core question is: what is a supported but non-configurable codec? How much validation to do in isConfigSupported()
16:24:51 <cpn> ... I initially thought to pre-validate as much as we can in isConfigSupported()
16:25:08 <cpn> ... Then I looked again yesterday, reevaluating, I guess what Firefox is doing seems OK
16:26:01 <cpn> ... The thing I thought was not ergonomic if we try to pre-validate as much as possible, and force descriptions to be there for isConfigSupported to return "supported", users might have to create a false description just to know they can play FLAC or > 2 channel Opus
16:26:22 <cpn> ... Chrome and Safari are out of sync with the current tests. The current tests say you don't need a description. I think that's OK
16:26:44 <cpn> Youenn: Safari doesn't use the description. Are you saying Safari isn't aligned with Firefox?
16:27:01 <cpn> Thomas: I haven't looked at how Safari fails the tests
16:27:25 <cpn> Youenn: I think we're OK not requiring a description in isConfigSupported(). Will check with Jean-Yves
16:27:33 <dalecurtis> https://wpt.fyi/results/webcodecs?label=master&label=experimental&aligned&q=audioDecoder-codec-specific.https.any.html
16:27:40 <cpn> Dale: The FLAC case is still busted with a description
16:28:11 <cpn> ... There's a bug i the tests, where there are tests for the opposite things. What you're proposing is OK.
16:28:50 <cpn> Thomas: This mirrors what we do on the video side. So can clarify the spec language and tests
16:28:55 <cpn> ... I can take an action to do that
16:29:35 <cpn> Eugene: It's a bit deeper for AVC, if you configure as AVCC you're supposed to have a description. So the precedence is that isConfigSupported() doesn't always require a valid description even if configure() does
16:30:29 <cpn> Topic: Timestamp handling, Issue 944
16:30:31 <cpn> https://github.com/w3c/webcodecs/issues/944
16:30:48 <cpn> Paul: Also https://github.com/w3c/webcodecs/issues/626
16:31:29 <cpn> Dale: Looking at 944, many audio codecs have priming information stripped away during decode
16:31:57 <cpn> ... Question is what we do with these samples. In WebAudio and media playback these are usually discarded and timestamps adjusted
16:32:20 <cpn> ... In WebCodecs it impacts the first time stamp coming from the decoder, e.g., a -10,000 timestamp, but there are 15,000 samples of padding
16:32:32 <cpn> ... So your first timestamp would be +5000
16:33:27 <cpn> ... Options: Never discard anything, and leave to the user. Or, make it configurable (ffmpeg and other libraries do this). Or, discard and shift the timestamps based on the initial timestamp given to us
16:33:47 <cpn> ... Following principle of least surprise I think we shuold do 2 or 3. I think some people will always want it done
16:34:04 <cpn> Paul: Agree. Firefox implements option 3, always remove
16:34:16 <dalecurtis> https://wpt.fyi/results/webcodecs/audioDecoder-codec-specific.https.any.html%3Fopus?label=master&label=experimental&aligned&q=Test%20decoding%20a%20with%20a%20negative%20timestamp
16:34:20 <cpn> Dale: Is that true? There's a WPT that FF is passing
16:34:37 <cpn> Paul: We have internal tests for that, not in WebCodecs
16:35:25 <cpn> ... We do use negative timestamps internally to signal samples to discard, but that might not be reflected in the WebCodecs API surface
16:35:37 <cpn> ... Timestamp 0 should be the first audible sample decoded
16:36:03 <cpn> Dale: That's largely true. So you think option 3 and there's a bug in firefox?
16:36:37 <cpn> Paul: Yes, I'm sure there are reasons not to want to do that. I care that the content round-trips nicely, you get what you expect, files should start at the same time
16:37:00 <cpn> ... One complication is for some AAC files where the right info is in the container and not the packets
16:37:16 <cpn> Dale: Also in AAC it's very deep in the codec and have to inspect it
16:37:38 <cpn> ... For those cases I assume the packets come from the container with negative timestamps, and the site could discard everthing before zero.
16:37:56 <cpn> ... Or have some mechanism to tell us what to discard
16:38:16 <cpn> ... If we have the priming information, there could be a double discarding problem, e.g., in Opus
16:40:02 <cpn> Paul: I care most about round tripping, and consistence. Not sure how to reconcile that with AAC edge cases
16:40:30 <cpn> Dale: The user has a workaround, they can handle if in the container. We can handle the bitstream ourselves
16:40:39 <cpn> Paul: And then the encoding side
16:40:55 <cpn> Dale: We could emit what the platform does in some cases, but in many cases we're guessing based on OS version
16:41:13 <cpn> ... Apple might be able to tell us what the true pre-skip is
16:41:47 <cpn> Dale: So let's close 944, if you think it's a bug in the test right now. I'll update the tests and leave a note in the issue
16:42:14 <cpn> Dale: On issue 626, not sure yet.
16:42:47 <cpn> Paul: Roundtripping is important. Amount of work needed isn't a lot
16:43:29 <cpn> Dale: It's labelled CR blocking. We can export information about what the codec is doing, what the site would need. I'd support emitting number of priming frames on the encoding side
16:44:06 <cpn> ... We could emit negative timestamps for priming frames, might be confusing even though it's symmetric
16:44:18 <tidoust> present+ Jer Noble
16:44:24 <cpn> Paul: I implemented a primingFrames attribute that would discard a number of frames. I think it worked nicely
16:45:00 <cpn> Dale: More concerned about the decoding side. How to reconcile the priming frames with information already available. LEss conentious on the encoding side
16:45:54 <cpn> Paul: With a regular MP3 you have to find the decoder delay, you pass the number, pass it to WebCodecs, then WebCodecs returns the first real audio frame intended to be heard
16:46:12 <cpn> Dale: In cases where the numbers match, that's easy to do. If they're slightly off, which do you prefer?
16:46:42 <cpn> Paul: That needs to be defined. We have a corpus of encoders in Firefox, all encoders and various we found
16:47:03 <cpn> ... I think it's workable. Our tests are sample accurate. But it does need to be well defined if the two disagree
16:47:15 <cpn> Dale: You have a prototype for encoding and decoding?
16:47:28 <cpn> Paul: The decoder side wasn't landed, it needed IDL changes
16:47:38 <cpn> ... I implemented the priming frame one, was simple
16:47:58 <cpn> ... We do have decode tests that are very precise. We could port that from our internal tests to WPT
16:48:07 <cpn> Dale: No strong opinion, just want it to be well define
16:48:23 <cpn> ... Can you update the tests and propose a resolution to the issue?
16:48:26 <cpn> Paul: Yes
16:48:41 <cpn> Dale: Do you have a proposal for padding also?
16:49:15 <cpn> Paul: I'll propose something
16:51:45 <cpn> Topic: Media Session
16:51:46 <cpn> https://github.com/w3c/mediasession/issues/377
16:52:23 <cpn> Jer: The purpose of exposing these things is that Media Session has a skip action for website that have interstitial or pre-flight ads, to indicate to the UA that the user can skip the ad
16:52:57 <cpn> ... We did this based on feedback from sites. But insufficient for some big sites, as they want the UA to present a button for the user to indicate interest in the ad
16:53:09 <cpn> ... E.g., a Buy or Install button
16:53:41 <cpn> ... We didn't want an open-ended, unlocalized text field, so we tried to come up with an initial set of verbs to indicate the user action
16:53:57 <cpn> ... This isn't a replacement for 'skip'.
16:54:15 <cpn> ... Personally, I'm not sure I'd use it, but some big video sites see this as critical.
16:54:43 <cpn> ... The proposal would be to have some metadata that the site could say the current action type, and a new "calltoaction" action
16:55:11 <cpn> ... Happy to get feedback on it. We're interest to implement, and we see site interest, and we'd want it to be interoperable and widely supported
16:55:34 <cpn> Alastor: If we declare a fixed set, what's the difference from adding a new action?
16:55:53 <cpn> Jer: We could add a set of new actions. Seems like an unnecessary explosion in the number of action types
16:57:15 <cpn> ... Expanding the list would mean expanding the action list vs the call to action types. The downside of having an enumerated set of types. Making it a single piece of metadata prevents websites shooting themselves in the foot, and if all those actions are supported simultaneously, which one wins?
16:58:46 <cpn> ... The request from the streaming sites, is the button has a label. We can install the callback, but if the label is added later. There's friction between those two calls. But I'd still prefer a single action with metadata than separate actions
16:59:09 <cpn> Alastor: Separate metadata sounds good to me. Then we can discuss what detail to add in the metadata
17:00:00 <tidoust> scribe+
17:00:33 <tidoust> Chris: Happy to get back to it in an upcoming Media WG meeting, typically next week. I'll email everybody.
17:00:44 <tidoust> RRSAgent, draft minutes.
17:00:44 <RRSAgent> I'm logging. I don't understand 'draft minutes.', tidoust.  Try /msg RRSAgent help
17:00:47 <tidoust> RRSAgent, draft minutes
17:00:48 <RRSAgent> I have made the request to generate https://www.w3.org/2026/09/03-mediawg-minutes.html tidoust
17:07:00 <cpn> i/WebCodecs issue #940/scribenick: cpn
17:07:07 <cpn> rrsagent, draft minutes
17:07:08 <RRSAgent> I have made the request to generate https://www.w3.org/2026/09/03-mediawg-minutes.html cpn
17:07:45 <cpn> i/Youenn: There's inconsistency/https://github.com/w3c/webcodecs/issues/940
17:07:46 <cpn> rrsagent, draft minutes
17:07:48 <RRSAgent> I have made the request to generate https://www.w3.org/2026/09/03-mediawg-minutes.html cpn