Adding a registration for H.263 #417
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,154 @@ | ||
| <pre class='metadata'> | ||
| Title: H.263 WebCodecs Registration | ||
| Repository: w3c/webcodecs | ||
| Status: NOTE-ED | ||
| Shortname: webcodecs-h263-codec-registration | ||
| Level: none | ||
| Group: mediawg | ||
| ED: https://w3c.github.io/webcodecs/h263_codec_registration.html | ||
| TR: https://www.w3.org/TR/webcodecs-h263-codec-registration/ | ||
| Editor: Yahweasel, Wereweasel https://wereweasel.com/ | ||
|
|
||
| Abstract: This registration is entered into the [[webcodecs-codec-registry]]. | ||
| It describes, for H.263, (1) the fully qualified codec strings, (2) the | ||
| codec-specific {{EncodedVideoChunk}} [=EncodedVideoChunk/[[internal | ||
| data]]=] bytes, (3) the {{VideoDecoderConfig.description}} bytes, (4) the | ||
| values of {{EncodedVideoChunk}} [=EncodedVideoChunk/[[type]]=], and (5) | ||
| the naming convention used in this document. | ||
|
|
||
| The registration is not intended to include any information on whether a | ||
| codec format is encumbered by intellectual property claims. Implementers and | ||
| authors are advised to seek appropriate legal counsel in this matter if they | ||
| intend to implement or use a specific codec format. Implementers of | ||
| WebCodecs are not required to support the H.263 codec. | ||
|
|
||
| This registration is non-normative. | ||
|
|
||
| Markup Shorthands:css no, markdown yes, dfn yes | ||
| !Participate: <a href="https://github.com/w3c/webcodecs">Git Repository.</a> | ||
| !Participate: <a href="https://github.com/w3c/webcodecs/issues/new">File an issue.</a> | ||
| !Version History: <a href="https://github.com/w3c/webcodecs/commits">https://github.com/w3c/webcodecs/commits</a> | ||
| </pre> | ||
|
|
||
| <pre class='anchors'> | ||
| spec: WEBCODECS; urlPrefix: https://w3c.github.io/webcodecs/# | ||
| type: attribute | ||
| text: EncodedVideoChunkMetadata.decoderConfig; url: dom-encodedvideochunkmetadata-decoderconfig | ||
| for: EncodedVideoChunkType; text: key; url: dom-encodedvideochunktype-key | ||
| text: VideoDecoderConfig.description; url: dom-videodecoderconfig-description | ||
| type: dfn | ||
| for: EncodedVideoChunk; text: [[internal data]]; url: dom-encodedvideochunk-internal-data-slot | ||
| for: EncodedVideoChunk; text: [[type]]; url: dom-encodedvideochunk-type-slot | ||
| for: VideoEncoder; text: [[output callback]]; url: dom-videoencoder-output-callback-slot | ||
| type: interface | ||
| text: EncodedVideoChunk; url: encodedvideochunk | ||
| text: VideoEncoder; url: videoencoder | ||
| type: dictionary | ||
| text: VideoEncoderConfig; url: dictdef-videoencoderconfig | ||
| text: VideoDecoderConfig; url: dictdef-videodecoderconfig | ||
| </pre> | ||
|
|
||
| <pre class='biblio'> | ||
| { | ||
| "H.263v1": { | ||
| "href": "https://www.itu.int/rec/T-REC-H.263-199603-S/en", | ||
| "title": "H.263: Video coding for low bit rate communication (03/96)", | ||
| "publisher": "ITU-T" | ||
| }, | ||
| "H.263v2": { | ||
| "href": "https://www.itu.int/rec/T-REC-H.263-199802-S/en", | ||
| "title": "H.263: Video coding for low bit rate communication (02/98)", | ||
| "publisher": "ITU-T" | ||
| }, | ||
| "H.263v3": { | ||
| "href": "https://www.itu.int/rec/T-REC-H.263-200501-I/en", | ||
| "title": "H.263: Video coding for low bit rate communication (01/2005)", | ||
| "publisher": "ITU-T" | ||
| } | ||
| } | ||
| </pre> | ||
|
|
||
| Fully qualified codec strings {#fully-qualified-codec-strings} | ||
| ============================================================== | ||
|
|
||
| The codec string begins with the prefix `"h263."`, with a suffix of 1 character | ||
|
There was a problem hiding this comment. I found one mention of "s263" in https://cconcolato.github.io/media-mime-support/. @cconcolato can you shed light on where that comes from and any thoughts on the scheme proposed herein? There was a problem hiding this comment. Looks like s263 is used for 3GPP, which is one of many "H.263 but..." codec specifications, as is MPEG-4 Part 2. I must admit, I'm wholly unaware of what the "but" part is; it may just be a particular restriction of features. There was a problem hiding this comment. 3GPP TS 26.244 defines the There was a problem hiding this comment. I would be happy to add the s263.profile.level strings as alternatives, but as mentioned in one of the threads here, the tricky thing with the H.263(+(+)) profiles is that they don't have any clean correspondence to the document revisions, but actual codecs implement document revisions, so not having a way to specify H.263 vs H.263+ vs H.263++ isn't really an option. |
||
| describing the version of the specification: `"h263.1"` for the first revision | ||
| ([[H.263v1]]), `"h263.2"` for the second revision ([[H.263v2]]), or `"h263.3"` | ||
| for the third revision ([[H.263v3]]). As the specifications are backwards | ||
| compatible, an encoder can encode using an earlier revision than specified, and | ||
| a decoder can decode using a later revision than specified. | ||
|
|
||
| `"h263.3"`, but no prior revision, can further be suffixed with a `"."` and a | ||
| one-character profile number, as specified in Annex X.2 of [[H.263v3]]. If a | ||
| profile is not specified, then an encoder can use any optional features and a | ||
| decoder needs to support all optional features. This can further be suffixed by | ||
| a `"."` and a two-character level, as described in Table X.2 of [[H.263v3]]. If | ||
| a level is not specified, then an encoder can support any level or can support | ||
| formats other than those in any specified level, and a decoder needs to support | ||
| any level and can support formats other than those in any specified level. | ||
|
|
||
| As revisions of H.263 prior to H.263v3 do not have profiles or levels, if | ||
| `"h263.1"` or `"h263.2"` is specified, then an encoder can support any optional | ||
| features in the specified revision, and a decoder needs to support all optional | ||
| features in the specified revision. The non-normative profiles and levels | ||
| specified in Appendix II are not used. | ||
|
|
||
| EncodedVideoChunk data {#encodedvideochunk-data} | ||
| ================================================ | ||
|
|
||
| {{EncodedVideoChunk}} [=EncodedVideoChunk/[[internal data]]=] is expected to be | ||
| a picture as described in Section 5.1 of [[H.263v1]], [[H.263v2]], or | ||
| [[H.263v3]], as appropriate for the used specification revision. | ||
|
|
||
| VideoDecoderConfig description {#videodecoderconfig-description} | ||
| ================================================================ | ||
|
|
||
| {{VideoDecoderConfig.description}} is not used for this codec. | ||
|
|
||
| EncodedVideoChunk type {#encodedvideochunk-type} | ||
| ================================================ | ||
|
|
||
| If an {{EncodedVideoChunk}}'s [=EncodedVideoChunk/[[type]]=] is | ||
| {{EncodedVideoChunkType/key}}, then the {{EncodedVideoChunk}} is expected to | ||
| contain an `INTRA` picture. The precise definition depends on the specification | ||
| revision: | ||
|
|
||
| H.263v1: `PTYPE`'s bit 9 (Picture Coding Type) is 0 (`INTRA`), as defined in | ||
| Section 5.1.3 of [[H.263v1]]. | ||
|
|
||
| H.263v2, H.263v3: If `PTYPE`'s bits 6-8 are not set to 111, then `PTYPE`'s bit | ||
| 9 (Picture Coding Type) is 0 (`INTRA`), as defined in Section 5.1.3. If | ||
| `PTYPE`'s bits 6-8 are set to 111, as defined in Section 5.1.3, then | ||
| `PLUSPTYPE`'s `MPPTYPE`'s bits 1-3 (Picture Type Code) are 000 (`INTRA`), as | ||
| defined in Section 5.1.4.3. Section numbers refer to [[H.263v2]] if the second | ||
| revision is used, or [[H.263v3]] if the third revision is used. | ||
|
|
||
| Notes on codec naming {#notes-on-codec-naming} | ||
|
There was a problem hiding this comment. I typically see codec strings break down by profiles rather than annexes. I appreciate that profiles came along pretty late here, but I wonder if they could still serve this purpose and thereby simplify the codec string scheme. At a glance, it looks like the profiles refer to combinations of features from earlier annexes. Would it work to simply have a string like h263.[profile]? There was a problem hiding this comment. The problem is that the profiles don't have a clean relationship with the revisions, but practical codecs are by revision. Profile 0 is only decodable with H.263v1, but doesn't use all of H.263v1's features. Profiles 1–3 are decodable with H.263v2, but don't use all of its features. Profiles 4–8 all require H.263v3. Any practical implementation is going to use off-the-shelf codecs, and in practice, the codecs are by revision. For instance, ffmpeg has "h263" (v1) and "h263p" (v2). |
||
| ============================================== | ||
|
|
||
| This registration codifies only the unamended H.263 specification revisions as | ||
| published by ITU-T. Each specification is named "H.263", so they are | ||
| differentiated by revision numbers. The specifications do not formally have | ||
| revision numbers, but the revision numbers used in this registration are | ||
| commonly used. Each revision is materially identical to the previous revision | ||
| with several separately published annexes added. This registration provides no | ||
| means of specifying the annexes independently of the specification revisions in | ||
| which they were included, so it is not possible to, for instance, specify | ||
| baseline H.263 with Annexes A through J but not L through T. H.263v1 includes | ||
| Annexes A through H, H.263v2 includes Annexes A through T, and H.263v3 includes | ||
| Annexes A through X. | ||
|
|
||
| H.263v2 is also known as H.263+ or H.263 1998. H.263v3 is also known as H.263++ | ||
| or H.263 2005. | ||
|
|
||
| MPEG-4 Part 2 specifies a video encoding format which is backwards compatible | ||
| with H.263 (H.263 streams can be decoded as MPEG-4 Part 2), but it is not | ||
| forwards compatible (MPEG-4 Part 2 streams do not decode as H.263), and it is | ||
| not covered by this registration. | ||
|
|
||
| Privacy and Security Considerations {#privacy-and-security-considerations} | ||
| ========================================================================== | ||
|
|
||
| Please refer to the [[WEBCODECS#privacy-considerations|Privacy Considerations]] | ||
| and [[WEBCODECS#security-considerations|Security Considerations]] sections in | ||
| [[WEBCODECS]]. | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Yahweasel just to be clear, is it your intention to be on the hook for future maintenance (PR reviews) for this doc?
@tidoust, any issue with that? For my part, happy to have the help, but I don't know relevant W3C rules offhand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is an issue in that, per process, "an editor must be a participant". I'm confident that we can find a suitable workaround though.
@Yahweasel could perhaps be granted an invited expert status, although note that has some licensing implications (the Patent Policy does not apply to this document, but the invited expert status is linked to the group as a whole, and the group develops normative specs), or simply switch to another official spec editor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would warn you that I'm not, in particular, an expert. I guess I'm an expert in the way that anyone is an expert (I fell into the digital media field and learned while falling), but even as such, my expertise is far more in audio than video. This whole rabbit hole is scratching a particular itch for another project. I intend to maintain that project, of course, and to that end, this is part of that. I don't particularly mind being on the hook for this document, as I expect that (a) there's not much maintenance involved for a codification of a codec that hasn't changed in 15 years, and (b) no one else cares about H.263 :) .