- From: <bugzilla@jessica.w3.org>
- Date: Sun, 12 Oct 2014 12:41:35 +0000
- To: public-html-admin@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27025
Bug ID: 27025
Summary: Video and audio elements should specify video/audio
formats, not implementations (codecs)
Product: HTML WG
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: HTML5 spec
Assignee: dave.null@w3.org
Reporter: thuejk@gmail.com
QA Contact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html-admin@w3.org,
public-html-wg-issue-tracking@w3.org
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)
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Sunday, 12 October 2014 12:41:37 UTC