Meeting minutes
3GPP liaison on IVAS
cpn: We received a liaison letter earlier from 3GPP around WebCodecs and the particular IVAS codec they are developing.
… We drafted a reply, based on input from Dale.
… I'd like for Paul and Youenn to also review this so that we're collectively happy with the reply. I emailed them directly.
marcos: I'll see if Jer can have a quick look as well.
cpn: There's a whole separate question about taking spec work. That led us to refine criteria for selecting codec registrations for the registry, and for example require implementers interest within the group.
… I think the reply is ready to go, I just want to confirm with everybody.
Call for consensus on Media Playback Quality
cpn: Question is whether to upstream the spec as-is in the HTML spec, or whether we should continue work in the Working Group. I wanted to get opinions from the group.
… I don't see responses to this other than my own. I wonder whether we should restart this in the hope that gets some attention.
… For the time being, I don't have the feeling I know what we collectively want to do.
Mark_Foltz: I think Sangwhan was proposing this. Hopefully, if you send again, he can reply on his own behalf.
cpn: I'm also aware he has similar suggestions for other specs.
Media Capabilities - Better define channels in AudioConfiguration
cpn: There was discussion on the configurations of the channels. Wolfgang looked into the MPEG DASH spec, where they have a list of them.
… It seems that the channels configuration is unused in implementations for the time being.
Mark_Foltz: I looked at the implementations. Firefox may check that there is a number in that value but does not do anything with it in any case. Same thing for Webkit.
… Given there is no implementation, a good question is whether we should keep it.
… I created a PR to alert readers that the feature is unimplemented and may be removed in the future.
alwu: I can check internally with the right people and report.
cpn: Yes, from my own investigation, I believe Firefox does check the value. But the question is whether that changes the returned value in any way.
alwu: I'll check (and also ask Paul to check the 3GPP reply).
Mark_Foltz: For MPEG DASH, this may mean looking and selecting the right bits in the media container. I would have to figure that out.
cpn: Should we take a decision today on replacing the feature with a note?
Mark_Foltz: Happy to wait for input from others, but the PR can also be merged in parallel if anyone wants to +1 it.
cpn: You suggested looking at what MPEG DASH does. At the moment, you cannot query information directly from a DASH stream, you have to look into the DASH manifest first.
Mark_Foltz: Right. Could it decode media from this particular media stream? We may need to invent another syntax if the stream is not from a MPEG DASH source.
… We may need to come with a universal syntax for channel layouts. That's some of the complexity.
cpn: Is there work to be done on the render side of things?
… If 5.1 is rendered to stereo, content provider may prefer to send the stereo audio.
… The Audio Output Devices API tends to be used in the WebRTC world.
Mark_Foltz: With it, you can get IDs, and you can plug these IDs to media elements. I'm not familiar with it though.
cpn: That's the one use case that we don't have an answer to yet.
… The answer may be that the decoder can decode whatever you feed it, but there may be different rendering capabilities, and we don't have a way to surface that to web applications.
… I do not know whether there is a major demand for this either. This is stretching the scope of Media Capabilities a bit.
Mark_Foltz: It's an interesting use case. For recorded media, you may want to avoid wasting the bandwidth, so I do see the use case.
… For games and XR, you may want to detect these capabilities.
cpn: This was the TPAC discussion where WebXR people were interested in this use case.
Mark_Foltz: For recorded formats, most things are passthrough, so the browsers wouldn't do anything.
… We have to do some research with codec experts to see what the parameters would be for channel preferences.
Incorrect definition for media element pseudo class :stalled
cpn: Alastor raised this issue against the HTML spec.
alwu: There are new pseudo classes added to media element, including :stalled.
… For :stalled, definition says it has to be playing and fetching at the same time.
… But the stalled event does not have any relationship with the play state.
… Jer replied that it was intended that :stalled definition differs from the stalled event. That solves my question.
… But the names are confusing. Some Web Platform Tests expect a symetry, which seems wrong.
… I can file a PR to mention that.
… The stalled event is only about the networking.
… But the pseudo-class also checks the ready state, which is confusing given that it has the same name.
… The pseudo-class is part of this year's Interop focus, so I'd like to clarify things.
cpn: I'm wondering about usage for this pseudo-class if you're proposing some changes.
alwu: I'm not planning to change the CSS definition. I just think they should clarify the relationship between the pseudo-class and the event.
cpn: OK, so no change. A PR along these lines to clarify seems a good thing to me.
<Mark_Foltz> May be partially implemented behind a flag in Blink. https://