Establish codec registry and AVC registration.

[chcunningham]

This moves codec-specific defintions / descriptions into a registry.
I've also added some text to the main document to clarify that support
for any given codec is not required.

Fixes #143. Fixes #126.

---

Preview | Diff

[chcunningham]

@tidoust FYI - this is what I'd like to land before the FPWD transition.

[chcunningham]

@aboba - looks like the pr-preview link at the bottom of the description only supports a preview of the main spec (known issue). Here are some links to the generated HTML to assist in review.

https://storage.googleapis.com/videostack-external/webcodecs_pr_149/index.html
https://storage.googleapis.com/videostack-external/webcodecs_pr_149/codec_registry.html
https://storage.googleapis.com/videostack-external/webcodecs_pr_149/avc_codec_registration.html

For now I've just done the AVC registration. Other registrations will be follow up PRs (not urgent, not blocking anything).

[chcunningham]

@padenot FYI

[tidoust]

See some comments inline.

I understand that the current final goal (pending evolutions of the W3C process to account for registries) is to publish the registry and the AVC registration as non-normative Working Group Notes. Is that correct?

[chcunningham]

I understand that the current final goal (pending evolutions of the W3C process to account for registries) is to publish the registry and the AVC registration as non-normative Working Group Notes. Is that correct?

Yes, that is correct. And we will seek to maintain the non-normative status of the registry and registrations as the W3C process evolves.

[tidoust]

I understand that the current final goal (pending evolutions of the W3C process to account for registries) is to publish the registry and the AVC registration as non-normative Working Group Notes. Is that correct?

Yes, that is correct. And we will seek to maintain the non-normative status of the registry and registrations as the W3C process evolves.

From a process perspective, this means that the specs need to be published separately. That is, we're going to publish three First Public Working Drafts:

1. The WebCodecs spec in itself, intended to become a Recommendation, under the shortname webcodecs
2. The registry spec, intended to become a WG Note, under the shortname webcodecs-codec-registry
3. The AVC (H.264) WebCodecs registration, intended to become a WG Note, under the shortname webcodecs-avc-codec-registration.

Practically speaking, tools such as PR preview and spec-prod are more or less designed for repos that contain only one spec. Splitting the specs to dedicated repositories as done for MSE (see list of repos) would simplify integration with these tools... That said, it also makes editing slightly more cumbersome, and it's certainly possible to workaround tools constraints.

Would you be open to creating dedicated repos for the registry and AVC WebCodecs registration specs? If so, two choices:

1. I can create the registry repos under w3c right away, initialize them with the appropriate content taken from this PR, and corresponding files can then be dropped from this PR before it gets merged. Good thing about this is that it means we'll keep this repo clean.
2. You'd prefer that PR to be merged before the actual repo transition. In that case, we'll just separate documents afterwards, but note that would mean we'll need to preserve the codec_registry.html and avc_codec_registration.html files in this repo, replacing them with empty HTML files with a meta redirect to their new locations (as also done in MSE).

I would do 1. and I'm happy to prepare that.

[aboba]

Question: What is the approval process for registry entries? The document mentions posting an Issue to the github. Is the expectation that the specification editors will do the review/approval on their own? Or that they will recommend a disposition to the WG who will then make the decision? Also, what happens if for some reason the Github repo is no longer active? IANA registries sometimes allow a successor mailing list or WG to be designated.

[chcunningham]

Question: What is the approval process for registry entries? The document mentions posting an Issue to the github. Is the expectation that the specification editors will do the review/approval on their own? Or that they will recommend a disposition to the WG who will then make the decision? Also, what happens if for some reason the Github repo is no longer active? IANA registries sometimes allow a successor mailing list or WG to be designated.

@tidoust @cwilso - pls weigh in on ^

[tidoust]

Question: What is the approval process for registry entries? The document mentions posting an Issue to the github. Is the expectation that the specification editors will do the review/approval on their own? Or that they will recommend a disposition to the WG who will then make the decision? Also, what happens if for some reason the Github repo is no longer active? IANA registries sometimes allow a successor mailing list or WG to be designated.

First, we don't yet have a clear and crisp process in place for managing registries at W3C. That is the purpose of ongoing discussions within the Process CG. See also the registries section of the presentation on Process 2021 during last TPAC. Hopefully, a future revision of the W3C Process will create a clear mechanism for registries at W3C.

The direction that this PR is taking is that the registry will be published as a WG Note. The Media WG would thus be in charge of updating it (and not only the editors). For maintenance purpose, W3C tends to keep WGs around forever. If we ever close the group, the W3C team would be in fine responsible for the maintenance of the registry (granted, in the W3C process, this is more aimed at maintenance of Recommendations than at the maintenance of Notes...).

Another group may be created to take over the maintenance of the registry if needed. One perfect illustration is the Media WG, which took over maintenance of MSE/EME and of their companion format registries from the HTML Media Extensions WG.

I do not know whether these possibilities need to be specified in the registry spec itself. The text in the requirements section of the WebCodecs registry seems to be based on the one of the MSE Byte Stream Format Registry.

W3C guarantees that archives of mailing-lists will be available forever. If you believe that this guarantee is crucial, it may be preferable to request that an email be sent to some W3C archived public mailing-list (as done for MSE/EME registries) rather than to request that an issue gets posted to a GitHub repository. That said, my understanding here is that the contents of the issue (codec string, common name, link to a public spec) will be integrated into the registry directly, so is there really a need for a strong guarantee with regards to availability of the issue over time? More precisely, is there a need for a stronger guarantee than the one that currently exists for all group discussions that take place in GitHub issue trackers?

[chcunningham]

From a process perspective, this means that the specs need to be published separately. That is, we're going to publish three First Public Working Drafts:

The WebCodecs spec in itself, intended to become a Recommendation, under the shortname webcodecs
The registry spec, intended to become a WG Note, under the shortname webcodecs-codec-registry
The AVC (H.264) WebCodecs registration, intended to become a WG Note, under the shortname webcodecs-avc-codec-registration.

LGTM

Practically speaking, tools such as PR preview and spec-prod are more or less designed for repos that contain only one spec.
...
Would you be open to creating dedicated repos for the registry and AVC WebCodecs registration specs?

I don't love it. WebCodecs is going to have a large number of "registrations" (see TODO's in the registry table), and having a git repo for each one sounds cumbersome.

It looks like spec-prod intends to remedy this soon. Reading the replies there, I conclude that this is widespread enough that the tooling should be updated. Meanwhile, am I correct that the current travis config happily supports multiple files (I think it publishes the entire out/ folder)?

Multi-spec PR preview is more of a nice-to-have since the workaround is trivial. The analogous feature request has less momentum. The maintainer's comments suggest its just a matter of staffing it.

The text in the requirements section of the WebCodecs registry seems to be based on the one of the MSE Byte Stream Format Registry.

That's correct. LMK if you find this in any way lacking.

More precisely, is there a need for a stronger guarantee than the one that currently exists for all group discussions that take place in GitHub issue trackers?

I think GitHub should be fine.

[chcunningham]

@aboba sounds like the text around process for registry updates is reasonable. Any other concerns that block approval?

[chcunningham]

Thanks everyone!