This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I'd like to request to add codecs as standard for the <video> tag. flv -> Very common on the web mpeg4 (many browsers have it but I can't see it specified) -> The high quality substitute for flv. H.264 (optional but useful) -> A lot used specially with mkv, these days. Xvid -> Lots of OS have native support for it (according to my research) and it's a fair step between the flv and mpeg4. For audio codecs: FLAC -> The standard these days to distribute in a lossless quality and a fair memory use (for a lossless audio). mpeg3 -> The standard audio these days. A good balance between quality and memory used. Speex -> The audio codec of choice by Flash player 10 for flv.
The HTML standard does not currently require support for any particular video or audio codecs, because it's clear that currently there's no format all browsers will support. This matches how it specifies <img> or <object> -- no particular formats are mentioned. When browsers finally all agree on a standard format, like maybe WebM, the spec might require that, but not before then. This was discussed at extreme length a couple of years ago. (Incidentally: FLV is a container format, Xvid is an encoder, and MPEG3 and MPEG4 are groups of standards. None are codecs. H.264, FLAC, and Speex are the only codecs on your list. FLAC is lossless, so would be a very poor choice for web-based audio players. H.264 is supported by IE9 and Safari, but not other browsers, because it's patented-encumbered. Speex is not supported for HTML5 audio by any browser that I know of.)
(In reply to comment #1) > (Incidentally: FLV is a container format, Xvid is an encoder, and MPEG3 and > MPEG4 are groups of standards. None are codecs. H.264, FLAC, and Speex are > the only codecs on your list. FLAC is lossless, so would be a very poor choice > for web-based audio players. H.264 is supported by IE9 and Safari, but not > other browsers, because it's patented-encumbered. Speex is not supported for > HTML5 audio by any browser that I know of.) I thought my sources were right and that those were all codecs. Sorry about that. I see if I can find another one that has the list of encodes so that I can show which ones I'm referring to. BTW, which codecs can FLV contain?
(In reply to comment #2) > (In reply to comment #1) > > (Incidentally: FLV is a container format, Xvid is an encoder, and MPEG3 and > > MPEG4 are groups of standards. None are codecs. H.264, FLAC, and Speex are > > the only codecs on your list. FLAC is lossless, so would be a very poor choice > > for web-based audio players. H.264 is supported by IE9 and Safari, but not > > other browsers, because it's patented-encumbered. Speex is not supported for > > HTML5 audio by any browser that I know of.) > > I thought my sources were right and that those were all codecs. Sorry about > that. I see if I can find another one that has the list of encodes so that I > can show which ones I'm referring to. The more codecs are supported in different browsers, the less interoperability you get. It's not good for the Web to want to introduce more variety on supported file formats - the target should be one, not all. > BTW, which codecs can FLV contain? It's a container like Quicktime, Ogg, Matroska, and MP4 - they can all support all codecs, even though you would not typically find all codecs in all formats. But as I said: the answer to this question doesn't matter - it's not desirable to support more codecs/containers.
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: Did Not Understand Request Change Description: no spec change Rationale: I'd be happy to specify a codec if you can suggest one that all the browser vendors are willing to implement.
Let's see if I can make these straight this time: mpeg4 (codec family) (many browsers have it, others don't and I can't see it specified) -> The high quality substitute for flv. Smartphones support it, PDA's support it, all players (from many I know) for WinNT, MAC & Linux support it, why wouldn't browsers support it? H.264 -> A lot used specially with mkv and flv, these days. This would allow to have many different videos with different extensions play in the browser. Xvid -> Lots of OS have native support for it (according to my research) and it's a fair "brother" of mpeg4. Also, those codecs are free to use (according to wikipedia) For audio codecs: FLAC -> The standard these days to distribute in a lossless quality and a fair memory use (for a lossless audio). mpeg3 (codec family) -> The standard audio these days. A good balance between quality and memory used. I shure hope this makes it more clear
(In reply to comment #5) > Let's see if I can make these straight this time: > > mpeg4 (codec family) (many browsers have it, others don't and I can't see it > specified) -> The high quality substitute for flv. Smartphones support it, > PDA's support it, all players (from many I know) for WinNT, MAC & Linux support > it, why wouldn't browsers support it? > > H.264 -> A lot used specially with mkv and flv, these days. This would allow to > have many different videos with different extensions play in the browser. > > Xvid -> Lots of OS have native support for it (according to my research) and > it's a fair "brother" of mpeg4. Also, those codecs are free to use (according > to wikipedia) > > For audio codecs: > FLAC -> The standard these days to distribute in a lossless quality and a fair > memory use (for a lossless audio). > > mpeg3 (codec family) -> The standard audio these days. A good balance between > quality and memory used. > > > I shure hope this makes it more clear You missed the vital bit of Hixie's reply: I'd be happy to specify a codec if you can suggest one that all the browser vendors are willing to implement. Until you can get all browser vendors to support the same baseline codec, no codec will go into the spec, no matter how many you suggest.
(In reply to comment #6) > > You missed the vital bit of Hixie's reply: > I'd be happy to specify a codec if you can suggest one that all the browser > vendors are willing to implement. > > Until you can get all browser vendors to support the same baseline codec, no > codec will go into the spec, no matter how many you suggest. I didn't miss it, I just misunderstood. To confirm I understood this time: So I 1st need to talk to the browser engine vendors and propose it and then come back here and propose the spec change?
(In reply to comment #7) > (In reply to comment #6) > > > > You missed the vital bit of Hixie's reply: > > I'd be happy to specify a codec if you can suggest one that all the browser > > vendors are willing to implement. > > > > Until you can get all browser vendors to support the same baseline codec, no > > codec will go into the spec, no matter how many you suggest. > > I didn't miss it, I just misunderstood. > To confirm I understood this time: > So I 1st need to talk to the browser engine vendors and propose it and then > come back here and propose the spec change? Indeed - once you find a codec that all browser vendors support in their Web browsers, the spec will follow.
Ok, I'll do it and check back later.
Just so we're clear here, browsers have considered implementing a common codec and were unable to come to agreement. Firefox, Chrome, and Opera refuse to support H.264 at all because it's not usable royalty-free, and IE and Safari refuse to support VP8 or Theora by default because they might be covered by unknown patents. So you'd either have to convince Mozilla and Google and Opera to drop their ideological commitment to a royalty-free web, or convince Microsoft and Apple to accept the patent risk of VP8 or Theora. You'll be unsuccessful at both, but feel free to try.
Ok, I'll do it and check back later.(In reply to comment #10) > Just so we're clear here, browsers have considered implementing a common codec > and were unable to come to agreement. Firefox, Chrome, and Opera refuse to > support H.264 at all because it's not usable royalty-free, and IE and Safari > refuse to support VP8 or Theora by default because they might be covered by > unknown patents. So you'd either have to convince Mozilla and Google and Opera > to drop their ideological commitment to a royalty-free web, or convince > Microsoft and Apple to accept the patent risk of VP8 or Theora. You'll be > unsuccessful at both, but feel free to try. My readings had told that H.264 was a free codec... If I try to look for it more deeper I can see that that is not true. Where can I find a list of free codecs that are available in a flv, mp4 and mkv containers (not necessary the 3 at the same time, I just need pairs of codecs)?
(In reply to comment #11) > My readings had told that H.264 was a free codec... If I try to look for it > more deeper I can see that that is not true. > Where can I find a list of free codecs that are available in a flv, mp4 and mkv > containers (not necessary the 3 at the same time, I just need pairs of codecs)? VP8 in MKV is now called WebM. VP8, Theora, and Dirac are royalty-free video codecs; Vorbis, Speex, FLAC, SILK, and CELT are open audio codecs (amongst some older ones). Of these, your highest chances of getting common support will be WebM and Ogg Vorbis (the first in a MKV container, the second in a Ogg container). While these codecs can certainly be used in other containers, there is no such common use, so you're better off sticking with the typical containers that they come in. But you should listen to Aryeh - you may find it hard to convince Apple and Microsoft to adopt these codecs.
mass-moved component to LC1