{TBD: remove next sentence before submitting for approval} This Charter is work in progress. To submit feedback, please use GitHub Issues where this Charter is being developed.
Over the past decade, a growing number of sound and imaging media formats have been established offering increasingly sophisticated user experiences such as High Dynamic Range (HDR) and Spatial Audio. On the imaging side, these media formats provide the technical means to facilitate increased spatial and temporal resolutions, higher bit depths, as well as varying color volumes and the mapping between them. Similarly, on the audio side, higher bit-depth, sample rates and more immersive surround sound and speech processing options are available. These experiences are facilitated through tools and technical mechanisms available to both professional and consumer content providers and are readily available for temporally linear content types. However, options to provide such experiences through the web are still limited as potential solutions are fragmented and often insular or significantly limited in capabilities among open source as well as commercial options. This typically results in incorrect presentation to an end user or even error messages. Therefore, there is a need to consider how to support modern audiovisual formats in web browsers. To alleviate friction in development and deployment, it seems highly beneficial to our community to synchronize open and commercial solutions so that they can co-exist within a W3C framework.
The scope of this community group is to provide a forum to discuss features of open and commercial audio-visual media formats that are relevant with web technologies used in browsers, TVs, and Smart TVs. In particular, this includes identifying and reporting if and how individual formats and their features are referenced, can be called from a web environment and query necessary information from a host system in meaningful ways. The interplay and synchronization among different formats is also considered.
These assessments include developments in adjacent fields like broadcast, OTT streaming, gaming and film-industry. This wide scope field is intended to identify immediate challenges influencing audio-visual web technologies that are not sufficiently covered by the active roadmap of other W3C groups. This includes current challenges as well as topics of mid-term relevance and future trends.
This group will liaise with other W3C Working Groups and Interest Groups to promote the features and requirements that it identifies.
The technical development of standards is not in scope for the Community Group. Standards development is expected to take place within the appropriate W3C groups if such a group exists, or within a dedicated Community Group when incubation is needed.
For current challenges, the group identifies changes beneficial to existing web APIs needed to support open and commercial sound and imaging media formats. In addition, relevant trends and developments will be reported. These observations will be raised in the relevant issue tracker for those specifications and, when appropriate, provided as one or more reports identifying challenges and opportunities to other W3C groups.
No Specifications will be produced under the current charter.
The group may produce other Community Group Reports within the scope of this charter but that are not Specifications, for instance requirements for new APIs, or future looking "technology landscape" overview reports.
The Community Group does not plan to create test suites or other software.
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
The W3C Code of Ethics and Professional Conduct applies to participation in this group.
The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.
Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA).
Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.
Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request, by raising an issue, or by adding a comment to an existing issue.
All GitHub repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
The group will conduct all of its technical work in public. All technical work will occur in the group's GitHub repository in preference to mailing list discussions. This is to ensure contributions can be tracked through a software tool.
Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group's public mailing list or to the group's GitHub repository.
This group will seek to make decisions through consensus. Typically, a document editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue).
However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
Any decisions reached at any meeting are tentative and should be recorded in a GitHub issue. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the decision process.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.