This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There seem to be some major confusion in the current HTML5 specification on the definition of a codec. Lets start by definitions: An *video coding format* is a standard for how a video is represented in a file or bitstream format. A *codec* is a specific program which can encode and/or decode a video coding format. As an analogy, Office Open XML is a file format (~=video coding format), and Microsoft Office is a program (~=codec) to read Office Open XML files. If there were an office document tag, it would be quite absurd if a hypothetical office document tag had "program=microsoft-office" instead of "format=docx". Nonetheless, the current HTML5 video/audio tags have a "codecs=" parameter. As such, the HTML5 video and audio elements should specify which video/audio coding formats are used, not which codecs can be used. Video/audio coding formats are standardized exactly so that users can choose which codec among several supporting the format to use. For example, if a HTML5 video element specifies the video coding format "MPEG-4 Part 2", then the user could choose between the codecs DivX and Xvid, both of which can decode video in the MPEG-4 Part 2 format. The current HTML5 specification has a "codecs=..." parameter for video/audio, but the meaning in the examples is obviously "format=..." . For example > <source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'> Where avc1.42E01E is obviously a format, not a specific codec implementation. I therefore propose that the "codecs" parameter be renamed to "formats". Note that the mimetype "type" parameter is a file type, like e.g. "video/avi" which can contain many different video/audio coding formats. Some examples from http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#the-video-element > If the media data can be fetched but has non-fatal errors or uses, in part, codecs that are unsupported, preventing the user agent from rendering the content completely correctly but not preventing playback altogether Features are unsupported, not codecs. It is obviously not the specs intention to dictate exactly which codec is used. It should say "uses format features that are unsupported". > DNS errors, HTTP 4xx and 5xx errors (and equivalents in other protocols), and other fatal network errors that occur before the user agent has established whether the current media resource is usable, as well as the file using an unsupported container format, or using unsupported codecs for all the data, must cause the user agent to execute the following steps: The video/audio element may use a format which is unsupported. To say that it uses "unsupported codecs" implies that the user has to use a specific program to decode the data, and can't use any codec which supports the video/audio format. See also: https://en.wikipedia.org/wiki/Video_coding_format (note: I wrote most of that article)
I believe *no* action is required for this bug, i.e., WORKSFORME is a good resolution. I say this because: "codecs" as used as a MIME type parameter is already well established in the MPEG and DASH communities, in which context it is to be interpreted as "using/requiring a software component capable of decoding/presenting the named format". I agree with the author of this bug report that this interpretation is a bit of a mismatch with a perhaps more formal use of the term codec, semantically speaking; however, this isn't the first such mismatch, and won't be the last. In any case, the definition of MIME type parameters and their usage is outside the scope of the HTML5 specification. HTML5 is just a consumer of these parameters.
> "codecs" as used as a MIME type parameter is already well established in the MPEG and DASH communities I agree that many people are often using the two meanings interchangably. Even though they are really two different things. I just keep seeing endless confusion whenever people are talking about and conflating the two. While professionals can probably understand the difference, it is unnecessarily confusing for people who do not a priori have a complete understanding. > this isn't the first such mismatch, and won't be the last How about trying to be precise, and get as few semantic mismatches as possible. HTML5 is still a draft; it can still be fixed. Browsers can still unofficially support the codecs=... version for compatibility, if the draft switches to format=... . > In any case, the definition of MIME type parameters and their usage is outside the scope of the HTML5 specification. HTML5 is just a consumer of these parameters. At the very least, the HTML5 specification should use unambiguous and precise language when talking about codecs versus video/audio coding formats. It currently doesn't. And explain why the codecs=... parameter isn't really a list of codecs.
(In reply to Thue Janus Kristensen from comment #0) > There seem to be some major confusion in the current HTML5 specification on > the definition of a codec. I don't think there is any confusion, even if the text could possibly be clarified to reflect what I describe below. > Lets start by definitions: > > An *video coding format* is a standard for how a video is represented in a > file or bitstream format. > > A *codec* is a specific program which can encode and/or decode a video > coding format. I understand your concern about ambiguous terms and about having text understood by as many people as possible but the definitions you give are actually not 100% correct. Codec should actually be viewed as the "coding (or decoding) algorithm" used to transmit a video. Examples of codecs are H.264/AVC, MPEG-4 Part 2, Ogg Theora, ... The actual software/hardware implementing it does not matter. That is how professional video users understand the term. It's unfortunate that the general public confuses the software/hardware tool with the algorithm. As for what you call "video coding format", this concerns only specific file formats such as files with extension .264 or .h264, but in practice people use "container formats", i.e. file formats capable of storing not only video data but audio, subtitle, metadata ... Examples of such formats are: MP4, WebM, MKV, Ogg, MPEG-2 TS, ... > > As an analogy, Office Open XML is a file format (~=video coding format), and > Microsoft Office is a program (~=codec) to read Office Open XML files. If > there were an office document tag, it would be quite absurd if a > hypothetical office document tag had "program=microsoft-office" instead of > "format=docx". Nonetheless, the current HTML5 video/audio tags have a > "codecs=" parameter. HTML does not define the "codecs" parameter. HTML5 refers to the RFC 6381 [http://tools.ietf.org/html/rfc6381] which defines a "codecs" parameter for MP4 files (and similar). > > As such, the HTML5 video and audio elements should specify which video/audio > coding formats are used, not which codecs can be used. That is actually the case. You understand "codecs" as software, while the editors and people working on this understand it as "the algorithm". > Video/audio coding > formats are standardized exactly so that users can choose which codec among > several supporting the format to use. For example, if a HTML5 video element > specifies the video coding format "MPEG-4 Part 2", then the user could > choose between the codecs DivX and Xvid, both of which can decode video in > the MPEG-4 Part 2 format. > > The current HTML5 specification has a "codecs=..." parameter for > video/audio, but the meaning in the examples is obviously "format=..." . For > example > > > <source src='video.mp4' type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'> > > Where avc1.42E01E is obviously a format, not a specific codec > implementation. I therefore propose that the "codecs" parameter be renamed > to "formats". Unfortunately, that is not possible. The MP4 file format has been vastly deployed for many years already and most software/hardware understand the "codecs" parameter as needed. Hope my explanation clarifies your confusion.
> That is actually the case. You understand "codecs" as software, while the editors and people working on this understand it as "the algorithm". Well, look at the other users than video compression uses the term codec, e.g. https://commons.apache.org/proper/commons-codec/ which contains e.g. a codec for athe base64 format. Clearly the term codec refers to the program, and not to e.g. the base64 format. I am not in doubt that the editors of HTML5 had the right concept in their head, but the terms they used were not very precise, and possibly wrong. > Codec should actually be viewed as the "coding (or decoding) algorithm" used to transmit a video. Examples of codecs are H.264/AVC OK, so take a look at section 0.5 of the H.264/AVC standard, which establishes the H.264/AVC format ( http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.264-200305-S!!PDF-E&type=items ) > The coded representation specified in the syntax is designed to enable a high compression capability for a desired image quality. [...] Encoding algorithms (not specified in this Recommendation | International Standard) So how can H.264/AVC be an algorithm, as you say, if it doesn't specify the algorithm to use? The term "codec" actually does not appear at all in the H.264/AVC specification, which I think is a good indication that "codec" is not an uncontroversial and clear word to use for H.264/AVC. > HTML does not define the "codecs" parameter. HTML5 refers to the RFC 6381 [http://tools.ietf.org/html/rfc6381] which defines a "codecs" parameter for MP4 files (and similar). Fair enough, changing from the codecs parameter is probably not feasible. But I still think the HTML5 specification should be more precisely formulated to avoid ambiguity around the "codec" term. And I still think rfc6381 is using the word "codec" wrongly, per my arguments above.
(In reply to Thue Janus Kristensen from comment #4) > I am not in doubt that the editors of HTML5 had the right concept in their > head, but the terms they used were not very precise, and possibly wrong. I agree the term can be misleading for non-experts. > So how can H.264/AVC be an algorithm, as you say, if it doesn't specify the > algorithm to use? I was too quick in answering. Algorithm is indeed not the best word. Video coding specifications define a bitstream syntax and provide sufficient information for implementors to implement encoding algorithms and decoding algorithms for this syntax. That's what I meant. > The term "codec" actually does not appear at all in the > H.264/AVC specification, which I think is a good indication that "codec" is > not an uncontroversial and clear word to use for H.264/AVC. That's one interpretation. > > HTML does not define the "codecs" parameter. HTML5 refers to the RFC 6381 [http://tools.ietf.org/html/rfc6381] which defines a "codecs" parameter for MP4 files (and similar). > > Fair enough, changing from the codecs parameter is probably not feasible. > But I still think the HTML5 specification should be more precisely > formulated to avoid ambiguity around the "codec" term. Maybe it should clarify that it uses the term "codec" to designate the decoding process associated to the video format identified by the MIME type including sub-parameters and implemented by the browser.
> I agree the term can be misleading for non-experts. Do you have a good authoritative source or two for the precise definition of codec? Wikipedia is not an authoritative source, but seems very clear on the point that a specification is different from its implementations, and an implementation (not the coding specification) is called a codec: https://en.wikipedia.org/wiki/Codec I have actually looked a good deal, without finding anything really good. Many other google results for "codec definition" seem fuzzy in their definitions.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Rationale: I think making an arbitrary distinction between codec and "video coding format" is weird. The word "codec" has been used for many years interchangeably for software that encodes and decodes, and for the specifications that define the bitstream syntax and algorithms of decoding (and approach to encoding). For example: http://www.theora.org/ talks about the "vorbis audio codec" and http://www.theora.org/faq/#10 talks about "Theora is an open video codec". After all, the specification is often just pseudo-code for an implementation, so making that distinction seems a bit arbitrary. As for the "codecs" parameter in the MIME type - that's not something HTML5 created, but is part of the MIME type definitions of IETF. Closing this as WORKSFORME.
> For example: http://www.theora.org/ talks about the "vorbis audio codec" Note that there actually exists an audio codec (=implementation) of the vorbis format named vorbis. > and http://www.theora.org/faq/#10 talks about "Theora is an open video codec". Note that there actually exists a video codec (=implementation) of the theora format named theora They are conflating the two yes, but the two projects actually contain both a format and an implementation under the same name.
Even this old Microsoft article talks about "codecs, like MP3, Windows Media Audio, and Windows Media Video" where it clearly means audio or video coding formats: http://windows.microsoft.com/en-au/windows/codecs-frequently-asked-questions#codecs-frequently-asked-questions=windows-8 The use of "codec" both for the specification and for implementations as a class of implementations has been around for a very long time. Using "codec format" and "codec implementation" to separate them is more likely to get you somewhere.