Meeting minutes
Status of the Audiovisual Media Formats for Browsers Community Group
<kaz> AV4Browsers CG
Timo: We started the group about 2.5 years ago
… The idea was to discuss how the linear media landscape that has developed, modern formats like HDR, high frame rates, audio with complex channel arrangements
… Things from the commercial world, and provide proposals and bring to the media groups
… We had a couple of meetings online, and at two TPACs. We brought one proposal forward that has made some progress
… The challenge now is we haven't had much activity in that group that couldn't be dealt with in MEIG
… The question is, by having additional groups, are we stretching ourselves too thinly?
… Is there a good reason to continue keeping that CG active, or should we make it dormant or even close it?
… I'll post a statement to the group's reflector later today
… There's some overlap with the groups. From our point of view, it would be ok to fold the activities into this group
Chris: We created the CG in a way that's quite aligned with this IG
… It's looking at use cases and requirements, but also because of the IPR issues,
… not designing solutions or developing technical proposals.
… Aligns closely with the way this IG is set up.
… We take the same approach, surfacing requirements not designing solutions,
… then bring those requirements to the relevant working groups.
… Another interesting role of this IG within W3C is that we have a number of liaison relationships
… with other SDOs in the media industry and within the wider W3C context any
… liaison-level exchange between SDOs tends to come through this group.
… It's another useful thing we can do here.
… I don't have a strong opinion about closing the CG.
… I'd like to keep working on the topics you've raised there.
… If we start to do that work here I'd hope that people would gravitate towards contributing here.
… I haven't noticed a lot of CG activity aside from what you've been driving yourselves,
… but from the interests of other people who have joined that group, I wouldn't want to stop them doing work.
… My suggestion is to continue the specific topics and build on them here.
… Announce to the groups that is what we plan to do and see what the response is.
… If it goes quiet in the CG that might indicate if we can close it later on.
Timo: We want feedback too rather than closing the group unilaterally.
… There are still valid ideas that maybe can be tackled more effectively through the IG
… I don't know if everyone in the CG is also in this group.
Nigel: It makes sense to me to bring the CG work here. I'd take a stronger line, and close the CG
<Zakim> nigel, you wanted to agree that folding the work of the CG into this IG sounds like it makes sense
Kaz: Thank you for rejoining W3C!
… I tend to agree with Chris's point and I'd like to suggest you talk to the CG participants
… again and clarify which parts of the CG are to be done by the IG and which still by the CG.
… For example your further communication feedback and so on.
Chris: I think the email Timo is proposing to send would surface that.
… The scope is around use cases and requirements there are no particular parts to split out.
… We would just continue it all here rather than leaving some topics there and some here.
Timo: My gut feeling is we post here and give ample time for people to reply.
… No feedback is actually good feedback to make a clean cut like Nigel proposes.
… Just keeping something running with no action is probably not helping our community.
… Finding a direction one way or another would be good.
… We're getting the impression that there isn't any CG work that can't come here to the IG.
Chris: Any other opinions or thoughts?
RobSmith: Thanks Chris, the only other thought is that the CG is free to participate in,
… so it is an accessible landing pad for new participants, so if someone is looking at the activities
… and wants to provide feedback that's an easy way to make a contribution rather than try to get
… into an IG meeting that is more strictly controlled, I understand why, so leaving the CG open
… is like an open invitation to others to participate.
… It sounds as though the existing participants are happy to transfer though.
Timo: Thanks for the comment, that's one of the reasons we started the CG, to give that forum.
… The question is whether it is acceptable for W3C and the wider community if it is ok for the CG to
… be basically a mailbox. If you keep it dormant it's okay by me but it may be fully inactive.
… Question for the structure of CGs in W3C.
<Zakim> Francois, you wanted to comment on dormant CGS
Francois: Just to react: we close the CGs these days rather than keeping dormant ones around.
… We try to be pro-active rather than giving a false impression of activity when there is none.
… In this case noone jumped on the possibility to join the discussion, or used the CG to raise new use cases
… or requirements, so I don't think there's any problem closing it now you're all on board.
Timo: I guess everything remains archived, so if we needed to reopen we could do that?
Francois: Sure, no reason, everything is archived.
… The IG mailing list is public and publicly archived too.
… Anyone can raise an issue, there's no strong barrier to participation in any case.
Kaz: If the CG is not active enough for a while, e.g. 6 months or 12 months, it will be closed automatically
… by the W3 Team, so you don't need to close it right away.
… Maybe in 6 months you can close the CG if there's no discussion.
Chris: Additionally, the IG has a public mailing list and people do respond to things.
… And a publicly visible GitHub, which sometimes attracts input from non-participants in our group.
… I think we can manage with the issue that Rob described because if people are paying attention
… to media things in W3C they are looking at this group and the WG and Web Audio WG, a small number
… of groups where the conversations are happening.
… Having fewer venues overall is more managable.
… An easy route into participation is important, it's a good point.
RobSmith: I agree, all good points.
… It might be worth making them when the CG is closed down so there's a record and
… people can navigate to the IG and mail them or go to the repo.
… Signposting.
Chris: Good suggestion
… I think we've reached a good path forward on this. Timo, I'm happy to coordinate with you
… to draft that message out to the group and include Rob's suggestion.
HDR formats in Media Capabilities
Chris: Shall we talk about the proposals in that group and see where we got to and what needs to be done next?
… In the agenda I linked to the last discussion that we had on this at TPAC last year.
<cpn> https://
Slideset: https://
Chris: I'll do a screen share, with your slides from last time.
… This was about the Media Capabilities API and specifically about commercial HDR formats
… where we have the HDR metadata type that refers to various SMPTE standards which may
… themselves, or may not be, commercial formats themselves, I'm not sure about the specifics.
… Then we added a proposal for an additional entry that talks about a format that hasn't gone through
… a standards body, so there's no SMPTE spec, but it is a well defined commercial format, and we need
… an identifier so that we can allow web apps to query for support for this format.
… We talked through different approaches like the way EME refers to the HDCP specifications and the
… different levels.
… We talked about having a Registry approach for the HDR metadata fields.
… Then the question is, if we have such a Registry, what document do we reference?
… Two questions: which identifier value should we use, and what is the reference document?
… For the Dolby Vision metadata there are a number of resources available, public specifications even if
… they are proprietary documents. We could reference those.
… That was the material presented.
… The discussion: how did we conclude?
Timo: I recall that the feedback was positive on doing something like this.
… In TPAC 2023 the proposal was a Registry instead of an enum.
… In TPAC 2024 the group asked why not an enum.
… From a functionality point of view both approaches are fine.
… We now need to work on which one to propose.
… Enums are more well defined in the long term.
… Registries can be changed more easily.
… Deleting obsolete ones might be easier.
… The question is what to hand over to the WG.
… The whole technical side is not rocket science, we just need to work it out and make a proposal.
Chris: Are there any other fields than the identifier needed?
Timo: From a Dolby side the most urgent request is for one identifier,
… but it might be beneficial to add more fields too, I'm not sure. Something that should be queried.
… If there is a flexibility to add more options that could be a nice add-on.
Chris: It might be interesting to describe what that looks like if what you've done is to maybe identify
… what a minimal change would be, but also if there's a more complete solution that would be better in some way.
… It would be interesting to capture both approaches, and if other vendors have requirements in this area
… then it would be interesting to see how those align.
Nigel: On the point about registries, the Process has requirements for how to do them. A key point is that the group that defines them must set the rules for if and how they can be changed
… If a concern is that registries are too flexible compared to an enum, that can be handled in the rules. For example, requiring new values for things that change. Or if you want to allow flexibility for obsoleting values, that can also be handled
… I'd advocate for using registries as a better choice, as long as you've captured the requirements. With enums they'd be specified in the Rec track document, then the cost of change is an update to the Rec track document
… A registry can decouple that. Another consideration is whether there's normative functionality based on the values. If there is, it has to be in the enum, as you can't put normative requirements on the behaviour of the registry entries
Timo: Thanks, that's good feedback
… This is what we want to learn. I need to look into that. I don't think we'd want to delete an enum, if a format disappears over time
… My feeling is that it's fine to keep around even for historical values
Nigel: The registry entry can have multiple fields. You could also indicate the status: proposed, active, obsolete, or whatever
… It could be a way to keep historical values
Timo: I'll take this to our team, will be good to move this forward
Wolfgang: Can we mix the enum and registry values? So in future registry values can be used?
Nigel: Why mix them?
Wolfgang: If they're enums today, you couldn't add registry values later
… It's a question about the entire set of values
… If we expect to add other values with non-normative requirements, could make the change now
… For the proposed value that started the discussion, it doesn't matter. I don't think normative behaviour is connected
Timo: One concern I recall was what happens to the existing enum values? Would they also go into the registry?
Chris: It's simplest overall to change it all over to the Registry.
… In terms of the implementation, in practice, there are tools that will generate
… implementations from enums. If an application that uses a value not in the enum it will
… be rejected with an exception. Once you move to the registry approach you're just passing
… strings so the user may or may not be passing in a known string in the registry so to preserve
… that backwards compatibility there would need to be additional behaviour specified,
… if the string that comes in does not match a known enum value then raise an Exception.
… Free functionality with an enum, but you don't get that by passing strings.
… The EME spec does this. I'm not sure what the behaviour is if you pass a string that
… is not a known Registry entry, but that would be something we'd have to define.
… Could mimic the enum behaviour and throw an exception.
… Or maybe it goes into an algorithm for querying support and you just get a "no" because we
… don't know what it is.
… There would be a behavioural change that we'd need to work through.
… The WG would need to figure this out.
… When Nigel was speaking you convinced me that Registries are a good idea and lets use it,
… for the reason of maintainability.
… We could have a stable spec where the only thing that changes is additions to the Registry as new
… formats get defined and that's a good reason to do it. You don't need to reopen the spec once it
… gets to Rec. That's how the EME HDCP versions have been defined as well.
Timo: If we go that way, we could look at the transfer function or the colour gamut too.
… There's nothing new today but something could come up, like more than 3 primaries or something like that.
<tidoust> [I don't think you'd want to throw an "invalid value" error to mimic an enum when a registry is used. A registry is also a recognition that the list of values is designed to evolve and that different implementations may support different values]
Timo: So there could be a good reason to change the structure so it's more flexible.
Chris: The easy thing at this stage is, if there are other parameters that you think would be useful
… in Media Capabilities, make a note, write them down to give a hint as to the kind of things we may
… want to query for that you can't do at the moment.
… That comparison between a single enum value or identifier we could add, vs that plus some other
… parameters. Am speaking vaguely because I don't know what you're thinking of in that regard.
… If you think that's an important consideration it is worth writing it down.
… Then we can go to the MediaWG and explain our reasoning and ask if they are comfortable
… and can do the editorial work to make it happen.
Timo: I will take this back and get back to you.
Kaz: In addition to the Timed Text Registry approach WoT WG is also using it for IoT ecosystem and
… the Registry approach is more flexible and can manage variations over specific registry entries,
… so I like to agree with Nigel and Chris here.
Chris: Final thing I'll mention is, ~half an hour before the meeting, I had an email from Thomas Stockhammer
… to say that in the WAVE XXX task force there's a need for us to collaborate and see what each other is doing.
… I suspect this is two halves of the same coin, having the functionality in Media Capabilities,
… and the work in how to test device compliance and so on.
AOB - TTWG updates
DAPT CR
Nigel: Two updates. On 11 March, TTWG published a CR of DAPT
<nigel> DAPT CR
Nigel: Dubbing and Audio Description Profiles of TTML2. It's also useful for transcripts and translations
… Can be a transcript of the audio in the media, or what's in the video image
… Made some good changes, to iron out complex use cases, on tracking what some text relates to in the media
… We welcome any implementation work, let us know.
… There's an EBU tool that does transcription and translation, and outputs that as DAPT
… The time is right to give implementation feedback, and feedback on the spec itself
IMSC 1.3
Nigel: The second thing I wanted to raise, we're beginning work on IMSC 1.3
<nigel> W3C TTWG seeks feedback on draft IMSC 1.3
Nigel: I wrote a message to send as liaison. You may have noticed we published the IMSC HRM as a Rec, and it doesn't include support for the image profile of IMSC
… So you can no longer assess the presentation complexity for image captions in the same way you can in IMSC 1.2
… The main motivation for IMSC 1.3 is to add superscript and subscript features
… But to manage the complexity in the spec, I'm proposing to remove the image profile
… We want feedback. If you want the image profile, let us know
… If you want something fixed in the image profile, also let us know
Meeting close
Chris: Thank you, there are a number of things for us to follow up.
… Let's see what we can do between calls.
… Next meeting May 6th.
… Would be good to make progress in between if we can on these.
… any final comments before we end?
[no comments]
Chris: Thank you all, see you in May, or at the AC meeting next week if you're there!
… [adjourns meeting]