Adding a registration for H.263 #417
There are no files selected for viewing
| 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 may encode using an earlier revision than specified, and | ||
|
There was a problem hiding this comment. nit: this doc has a lot of "may" and "must", which are unfortunately reserved for normative documents (telling implementers what they must/may do). We have to find alternative phrasing (ex: #340) There was a problem hiding this comment. I didn't cap and em them because I assumed that was reserved for normative documents. Are "should" and "ought" reserved? There was a problem hiding this comment. The list is herre: https://datatracker.ietf.org/doc/html/rfc2119. There was a problem hiding this comment. "Can" and "needs to" it is ;) |
||
| a decoder may decode using a later revision than specified. | ||
|
|
||
| `"h263.3"`, but no prior revision, may 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 may use any optional features and a | ||
| decoder must support all optional features. This may further be suffixed by a | ||
| `"."` and a two-character level, as described in Table X.2 of [[H.263v3]]. If a | ||
|
There was a problem hiding this comment. Are levels in H.263 inter-compatible, as in, can an encoder output a lower level than requested like we have defined for H.264? There was a problem hiding this comment. With the exception of level 45, each level is strictly looser than all previous levels, so an encoder outputting at, e.g., level 10 is correctly outputting at level 20 or 30 or 40. 45 is an exceptional case, and while all streams in level 45 are also valid bitstreams in all higher levels, it is not true that all valid bitstreams at lower levels are valid as level 45. Because 45 is a weird exception, but all other levels are inter-compatible, I think it's easier to leave that as implicit, rather than repeating the document's rather long-winded explanation of their intercompatibility that I've just detailed here :) |
||
| level is not specified, then an encoder may support any level or may support | ||
| formats other than those in any specified level, and a decoder must support any | ||
| level and may 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 may support any optional | ||
| features in the specified revision, and a decoder must 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 may 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]]. | ||
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 :) .