Talk:HTML video

Page Out of Date

Most of the material and sources seem to be from 2010 and highly out of date. References to Youtube should now be updated, since they have switched to HTML5 player by default. — Preceding unsigned comment added by 183.89.94.215 (talk) 14:35, 29 July 2015 (UTC)

AV1

The AV1 codec of Alliance for Open Media Video. — Preceding unsigned comment added by 2800:810:43F:8352:71B6:EDBA:ACD5:54AD (talk) 17:26, 6 August 2017 (UTC)

Controls

That "controls" part needs to be elaborated on. THANKS -- 202.130.181.213 (talk) 11:05, 18 February 2010 (UTC)

Relationship to object element

The article should mention how video relates to object, an older tag that can also be used to embed video or other data. For example, it should describe their implementations' similarities and differences, their limitations relative to each other (what can video do that object can't, and vice versa?), whether the HTML5 editor(s) were aware of object's ability to show video through e.g.

<object data="movie.ogv" type="video/ogg"><!-- type may be overridden by HTTP Content-Type [1] -->
<param name="controls" value="controls" /><!-- hypothetical param that may depend on player -->
your browser does not support the object tag, or lacks a player for Ogg video
</object>
<!-- [1] http://www.w3.org/TR/html4/struct/objects.html#h-13.3 -->

(if a default player exists), and whether the HTML5 editor(s) intend(s) video to complement or replace object for its uses. --an odd name 20:58, 23 February 2010 (UTC)

Anyone? :( --an odd name 23:25, 21 March 2010 (UTC)

<object> is a catch-all thing that can be used to do pretty much anything, including including images, video, audio, script, whatever. I wouldn't say that <video> is related to it any more than <img> is. (Some browsers support SVG in both <object> and <img>, for example.) —Aryeh Gregor (talk • contribs) 18:26, 22 March 2010 (UTC)

Open Source

Open source can have many meanings, and open source licences can carry restrictions. Do we know that the proposed Google open source release of the On2 codecs will make them free? Stephen B Streater (talk) 17:49, 13 April 2010 (UTC)

Everything we say will just be speculative until Google's official announcement.
--Gyrobo (talk) 18:12, 13 April 2010 (UTC)

Open source software as defined by the OSI means almost exactly the same thing as free software as defined by the FSF. Google releases tons of free/open-source stuff and knows perfectly well what counts as free/open-source. I expect it will be released either completely patent-free, or with only patent defense clauses. But the details are indeed speculative, which is why we can only repeat the exact terminology our sources give. —Aryeh Gregor (talk • contribs) 18:25, 13 April 2010 (UTC)

So perhaps Gyrobo or another editor would like to reverse his revert of my edit which says that we don't know yet.[1] Stephen B Streater (talk) 20:03, 13 April 2010 (UTC)

No, because the current text is just what the source says. Any further inferences would be speculative.
--Gyrobo (talk) 21:01, 13 April 2010 (UTC)

Yes - I see now. Stephen B Streater (talk) 21:38, 13 April 2010 (UTC)

This news source specifically mentions royalty free as opposed to open source. It also covers the background to this issue. Stephen B Streater (talk) 09:56, 19 April 2010 (UTC)

Ambiguity of article's note section

E. g.: "Any format supported by QuickTime on OS X."

Does this mean: Safari supports any QT format on OS X, or any format that QT itself supports on OS X? -- 91.11.218.75 (talk) 23:01, 21 April 2010 (UTC)

It means "Safari will play any format that the QuickTime multimedia framework will play", specifically Ogg Theora when XiphQT is installed.--129.241.30.66 (talk) 09:13, 1 May 2010 (UTC)

Absence of patents vs. patents being licensed royalty-free

This article is confused about the patent situation on Theora. See http://theora.org/faq/#24 Hsivonen (talk) 12:00, 24 April 2010 (UTC)

Table of browser support is misleading

Except for (the minority of) browsers that have builtin codecs, the support for multimedia formats is not a question of browser, so don't present it as such. In these cases, the information is only normative. Don't mix normative with factual.

Examples: Konqueror seemingly supports Theora and not H.264, although the note correctly says Phonon can support any format. It's just that 99% of all Konqueror users use GNU/Linux, which tends to have support for ogg formats as a baseline. Safari and IE9 seemingly does not support Theora, but as we know from Safari, it's not a browser issue. Little is known about IE9 yet, but if it uses the native Windows multimedia framework, it too should play Theora when the directshow filters are installed unless it refuses to. My point is: It's not a fact.--129.241.30.66 (talk) 10:13, 1 May 2010 (UTC)

This confusion just proves why a comparison table for web browsers is useless; a comparison table for rendering engines would clarify this issue, and there is a comparison page specifically for that.
--Gyrobo (talk) 23:03, 1 May 2010 (UTC)

I temporarily reverted the changes you made, until we can reach a consensus on this issue. I don't disagree with you about the importance of emphasizing backend support, but the old table was easier (for me at least) to understand.
--Gyrobo (talk) 23:09, 1 May 2010 (UTC)

The old table is better for understanding/reading! mabdul 08:49, 2 May 2010 (UTC)

Okay, so there exists a sane table, but my table was more detailed. I am not giving up.--129.241.30.66 (talk) 05:06, 3 May 2010 (UTC)

You could help us there! These tables are more technical and I think you edit would be more useful there! mabdul 08:10, 3 May 2010 (UTC)

Reorganization of HTML5 video table

There needs to be some sort of metric we can use to determine whether a browser supports HTML5 video or not... I propose the following set of conditions for the browsers.

• Using the latest operating system

  For Windows and Mac OS, this would be Windows 7 and Mac OS X Snow Leopard respectively. For Linux I suggest Ubuntu 10.04 LTS since the Ubuntu distribution has the largest and majority market share of all the desktop Linux distros.

• Default installation settings

  For the operating system bundled browsers (Internet Explorer for Windows, Safari for Mac OS, and Firefox for Linux), we judge their HTML5 support based on what they can play out-of-the-box, and without any additional software or codecs. With regards to future software versions such as the upcoming Internet Explorer 9, the only change would be that the newer version is installed instead of the older version, and still without any additional software or codecs.

  For the non-bundled browsers (Chrome and Opera), we judge their HTML5 support based on what they can play on a Windows 7 installation since it has the largest market share out of all the latest operating systems, and is more representative of what the average user can expect when they use the browser for HTML5 video. With the exception of the browser software itself, the no additional software or codecs rule apply.

• Limit the number of browsers to be represented in the table to only the top five in usage share

  Altogether they make up about 99% of the browsers used on the web today. It's what is done for the browser and operating system usage share articles. The behavior of the other browsers concerning HTML5 can be noted in footnotes after the table and/or on their respective articles, especially those about multimedia frameworks.

These conditions should be noted in some form in the table. Either way I believe the table would be more organized if the readers can simply have a 'yes', 'no' or 'in development build' answer for the browser they want to check on. --112.203.100.68 (talk) 11:23, 4 May 2010 (UTC)

• Using the latest operating system

  The operating system isn't relevant for support. There may be some peculiarities (like Opera using GStreamer and supporting H.264 on Linux/FreeBSD), but that would be easier to explain with a note.

• Default installation settings

  I agree, browsers should be described by their out-of-the-box codec support. Chrome Frame and XiphQT are nice in notes, but the point of comparison tables like this is to compare the software itself, not plugins.

• Limit the number of browsers to be represented in the table to only the top five in usage share

  There was a discussion on Talk:Comparison of layout engines (Cascading Style Sheets)#Adding new engines about this type of thing, and I still believe what I said there: that yes, for purposes of statistical importance and verifiability, we should definitely limit the number of engines.

• Either way I believe the table would be more organized if the readers can simply have a 'yes', 'no' or 'in development build' answer for the browser they want to check on.

  That's pretty much how it's set up right now. There are all those depends on Others, but those all include notes for the backends.

--Gyrobo (talk) 20:22, 4 May 2010 (UTC)

Let's not oversimplify:

• To "simply have a yes and no" makes it easy, yes, easy to ignore the facts. With a few exceptions, 'yes' or 'no' is a lie. You're talking about developers. Who needs web developers who make false assumptions based on browser sniffing? Most assumptions based on this table will be false. This table is dangerous because the whole idea of "browser support for video formats" is oversimplified.
• We want "to compare the software itself, not plugins". Yes, Chrome Frame is uninterresting since you're then essentially comparing a different browser. XiphQT however, has nothing to do with browsers. Safari (the software itself) supports Theora. Period. Likewise, Konqueror and Epiphany support H.264. The table gives a different impression, which is a factual error, inevitable when presenting an oversimplified image.
• "The operating system isn't relevant for support." I'm aware you're referring to the version of the OS, but let me correct anyway: The OS, specifically the multimedia framework, alone dictates the browser's video format support, except for browsers with builtin codecs. Only true multiplatform browsers have builtin codecs because being able to rely on a versatile backend is favorable for simplicity and flexibility. Having said that, I don't believe one millisecond that IE9 only supports H.264, they just want to state their position in the format war.--129.241.30.66 (talk) 20:55, 15 May 2010 (UTC)

1. I think you meant to say that Safari doesn't support Theora.
2. I agree that this table is dangerous and simplified, because it refers to web browsers instead of layout engines. That's what Comparison of layout engines (HTML5 Media) is meant to correct.
3. I did mean that the OS itself isn't relevant. The table is about native video support, which includes only the codecs included consistently on all supported platforms. This is another case where a comparison of only rendering engines would resolve the issue. If a browser is capable of supporting more formats directly through an external backend, that's note material, but not indicative of native support for the purpose of this table.
4. Whether or not anyone believes that IE9 will only support H.264 is undebatable unless and until Microsoft says it plans support for other codecs. It hasn't.

--Gyrobo (talk) 00:17, 16 May 2010 (UTC)

I think we should have "yes" when it supports with the default configurations, and "depends" when it relies on third party codecs. Or perhaps we need another possible category ("plugins-available"). For instance, IE9 will apparently allow VP8 *if codecs are installed*, while simply refusing to add Theora support. Theora's "no" is different from VP8's "no". Luiscubal (talk) 22:07, 20 May 2010 (UTC)

Perhaps we should transclude Template:Explanation of the tables2, like the comparison pages do?
--Gyrobo (talk) 22:16, 20 May 2010 (UTC)

Definitively, but besides that. I think "depends" clearly indicates that a property is supported only on specific cases, which is true for IE9 VP8 support. Luiscubal (talk) 21:41, 21 May 2010 (UTC)

However, we should be consistent with Safari's Theora support. Either both Safari and IE switch to depends, or both stay on "No" with a note. Whatever we decide here will also apply to Comparison_of_layout_engines_(HTML5_Media). Luiscubal (talk) 21:45, 21 May 2010 (UTC)

Both Theora for Safari and VP8 for IE should be "no". The table is comparing default codec support, not support through third-party software. Both XiphQT and the DirectShow filters are not part of any default install. That's how Comparison of layout engines (HTML5 Media) treats the layout engines. WebKit is listed as "depends" on many codecs because WebKit browsers (Safari, Chrome) each support different codecs exclusively. Only codecs that are supported universally, across all WebKit browsers are listed as a solid "yes". That's my view of it.
--Gyrobo (talk) 22:11, 21 May 2010 (UTC)

That, however, puts IE9's Theora and VP8 support in the same category (as I stated above), which is not correct. No native support != No support at all. However, we do not list JS framework/plugin support as "Depends" in other comparisons, so that this lack of distinction might be acceptable Luiscubal (talk) 18:27, 24 May 2010 (UTC)

I don't see the purpose of the table unless it's (exclusively) describing native support. Any browser can support any codec using the right combinations of plug-ins. The point of HTML5 media elements is to provide support without plug-ins.
--Gyrobo (talk) 18:39, 24 May 2010 (UTC)

Very well, then. "No" it is. However, we should still add a note to the page, or mention somewhere in the page that these values are only about native support and exclude the possibility of installing additional codecs. Luiscubal (talk) 22:14, 24 May 2010 (UTC)

 Done I changed the title at the top of the table to say "Native video support". Is that descriptive enough? This issue has caused so much confusion, let's make sure to clarify this perfectly.
--Gyrobo (talk) 22:21, 24 May 2010 (UTC)

I think so. Luiscubal (talk) 22:33, 24 May 2010 (UTC)

I disagree. I think the table should distinguish between "No support and can't be added" and "No support out-of-the-box but can be added by installing a codec". It's a very meaningful distinction.Hsivonen (talk) 13:29, 26 May 2010 (UTC)

The table does distinguish this, through notes in the affected cells.
--Gyrobo (talk) 13:55, 26 May 2010 (UTC)

The policy of "native support only" means that Opera, Konqueror and Epiphany no longer supports H.264. Just like Safari and IE9 does not support Theora, but the other way around. I still think the policy is misguided, but a fair comparison is more important. Regarding IE9, we have no reason to believe it supports Theora any less than VP8. Remember, I correctly predicted it uses DirectShow filters, despite all sources saying "only H264", which I think demonstrates my understanding of how these things work, as opposed to what Microsoft wants people to believe.--129.241.30.66 (talk) 01:01, 25 May 2010 (UTC)

Excuse me, but just because a browser uses DirectShow, that doesn't mean it supports all codecs DirectShow supports. Security and stability issues may cause browsers to have whitelist-based codec support. And Microsoft *DID* claim they would only support H.264. They recently changed the statement to "supporting VP8 if installed", so that means their whitelist(the only possible way they have to make sure the browser uses only these two codecs) includes both H.264 and VP8. Maybe IE9 does lack a whitelist, but we need a reliable source to claim that(since original research and blind guessing is forbidden by Wikipedia rules). —Preceding unsigned comment added by Luiscubal (talk • contribs) 18:12, 27 May 2010 (UTC)

Don't you see the difference between a codec and a browser plugin? Codecs have nothing to do with browsers. Not their layout engines either, by the way. This is an OS issue. Why not rather make a table of "OS support for video formats" instead? This is just misleading--129.241.30.66 (talk) 01:01, 25 May 2010 (UTC)

at first it would be good to register, ip ;) the os means only that every browser supporting the native apis would also play the video in the browser and the video would be encoded by the os: that would only in IE (in Win) and Safari (in Mac OS X)[and maybe OWB]... a plugin must be installed by the user (or in the case of IE and Safari:Mac by the os related update routine like windows update). since that is not the case in most cases the codecs are relevant to the installed browser and this table is correct at the moment. beside that we need only to wait a few months and the new browsers will be released and every problem will be solved by time. this is really a short (time) problem. mabdul 01:19, 25 May 2010 (UTC)

WOW, never thought that my "Explanation of the tables2" template would ever get in more article except the comparisons of layout engines! good work for you all! I give my go to Gyrobos opinion at the moment! mabdul 00:11, 25 May 2010 (UTC)

Can we now limit the number of browsers to be represented in the table to only the top five as suggested before? I just noticed that the bottom three browsers -- Konqueror, Epiphany, and Origyn -- rely on the multimedia framework of the operating system. This trait can be summarized and is in fact now represented in comments beneath the table with the mentions of Phonon and Gstreamer respectively. I suggest that comment be expanded to include Konqueror and Epiphany as examples of browsers that use Phonon and Gstreamer frameworks for HTML5 video, and make a new entry for Origyn in the comment as an example of a browser that use FFmpeg framework for HTML5 video. --112.203.100.68 (talk) 07:02, 26 May 2010 (UTC)

• If you want to separate cross platform browsers from the ones using multimedia frameworks, I totally agree. Just remember that DirectShow and QuickTime are multimedia frameworks, which leaves only Firefox, Opera and Chrome in the table. Brilliant, because the table would not be misleading any more: The table wants to compare "natively supported formats". Where "native" refers to the operating system, this is of course a (disguised) comparison of operating systems!
• I don't agree to limiting attention to the top 5 browsers. If the reader is interested in technological advances and possibilities with HTML5, we would want to show its broadness of support. Does it succeed where Flash fails? If statistical significance is interesting, please leave browser statistics for the reader to interpret. As a Konqueror user, I know the statistics are utterly wrong because my browser gets counted as Safari.--129.241.30.66 (talk) 23:15, 7 June 2010 (UTC)

I think the current table is bogus in the following ways:

• Safari is one row in the table. It should be three: Mac, Windows and iOS. On Mac, H.264 should be Yes, and Theora (XiphQT) and WebM (Perian tip of the tree) should be Depends. On Windows, Theora (QuickTime plus XiphQT) should be Depends and even H.264 should be Depends, because Apple offers a download without QuickTime. AFAIK, there's no Perian-equivalent for Windows QuickTime ATM.
• Opera should be two rows: Mac/Windows with Theora and WebM as Yes and H.264 as No; and Linux/FreeBSD with H.264 as depends
• H.264 support between Opera and Konqueror/Epiphany is inconsistent: If installing a GStreamer plug-in is Depends for Opera, surely it should be Depends for Konqueror/Epiphany, too.
• H.264 and WebM support for Konqueror/Epihpany is inconsistent: If WebM is Depends with a GStreamer plug-in, surely H.264 should be, too. They even refer to the same note!
• The "Others" column doesn't really contribute anything of practical relevance.

The reason why I don't just do the edits is that I expect Gyrobo would just revert me just like before when he reverted my edit and effectively claimed pluggable codecs for GStreamer and QuickTime weren't analogous. Hsivonen (talk) 11:10, 28 August 2010 (UTC)

There are 2 kinds of browsers: {any format, specific formats}

Specific formats

The format support of these browsers is set at compile time. They may use codecs and libraries internally, but they are not pluggable.

Browser	Supported formats
Mozilla Firefox	Theora, (WebM planned for version 4)
Opera for Windows and Mac OS X	Theora, WebM
Google Chrome / Chromium	Theora, WebM
Origyn Web Browser	Theora, WebM, H.264 in version 1.9 for MorphOS (uses FFmpeg internally).

Any format

The format support of these browsers is solely dictated by their backend, and their backend permits codecs to be plugged in and out.

Browser	Multimedia backend
Internet Explorer	DirectShow
Safari	QuickTime
Konqueror	Phonon
Opera for GNU/Linux and BSD	Gstreamer
Epiphany	Gstreamer
BOLT browser	default external media player

Availability of codecs for pluggable multimedia backends

Multimedia backend	Theora	WebM	H.264
DirectShow	with Opencodecs (Xiph's DirectShow filters)		with Windows
QuickTime	with XiphQT		with Mac OS X
Gstreamer	with gstreamer-plugins-base	with gstreamer-plugins-bad	with gstreamer-plugins-bad
Phonon	Phonon uses either Gstreamer or Xine as backend. Phonon backends using Mplayer and VLC are in development.

This is the exact reality. Why decompress reality into a big matrix of not-so-exact information plus notes & exceptions, like trying to reach an incompetent audience? --129.241.30.137 (talk) 00:23, 11 January 2011 (UTC)

Regarding support notes

In the browser support table, note 1 says: "Indirectly possible if Google Chrome Frame is installed". This note applies to Theora and is accurate as far as I know. However, regarding VP8 support, only reference to installing the codec on the system is made. Won't Google Chrome Frame support VP8 just like it supports Theora? Or are we waiting for citations that this is indeed possible? As for note 3, I propose changing it to "Indirectly possible if both IE Tab and Google Chrome Frame are installed". Small difference, but makes it clearer that the "and" is intentional.Luiscubal (talk) 18:45, 6 June 2010 (UTC)

HTML5 audio

shouln't we crerate also a seperate page for html5 audio? or rename this article to html5 media and create two red.? I've create one for html5 audio to the comparison, but I'm not really happy about this state! mabdul 12:06, 13 August 2010 (UTC)

An article would be created if there was enough content. Right now, HTML5 video is mostly about the format debate over a default codec, and usage. There hasn't been such a large debate over HTML5 audio, and HTML5 audio usage hasn't been as prominent as video. If you find enough sources for HTML5 audio deployment, we should include it in a single media article, or separate HTML5 audio article.
--Gyrobo (talk) 00:03, 14 August 2010 (UTC)

Technically any format debate which applies to video also applies to audio because AAC is also a patented codec which must be licensed for usage. Same goes for MP3 - it's not a royalty free codec either. The fact that nobody is debating audio codecs in the context of HTML5 just goes to show how little the people who are debating these matters actually understand about the context. —Preceding unsigned comment added by 67.40.16.99 (talk) 20:53, 25 March 2011 (UTC)

Problem line

H.264/MPEG-4 AVC is widely used, and has good speed, compression, [...] and video quality

Any sources for this statement other than Apple and TUAW?

Please don't argumentum ad hominem me for not being logged in either.

90.201.84.1 (talk) 18:10, 18 November 2010 (UTC)

H.264/MPEG-4 AVC and patents

Is it only me, or these two statements are not compatible? In my reading, the first one seems to suggest that H.264 is not covered by patents.

1. "Formats like H.264 might also be subject to unknown patents in principle, but they have been deployed much more widely and so it is presumed that any patent-holders would have already sued someone."
2. "H.264/MPEG-4 AVC is widely used, and has good speed, compression, hardware decoders, and video quality, but is covered by patents."

Maxferrario (talk) 13:27, 30 November 2010 (UTC)

They are compatible. The first sentence does not suggest that H.264 is not covered by patents, it suggests that just like Theora (or anything else), it can be covered by unknown (third-party) patents, too, in addition to the known ones licensed by MPEG LA.—J. M. (talk) 15:44, 30 November 2010 (UTC)

Where's the video?

I have a question about the location of the video. In our example...

<video src="movie.webm" poster="movie.jpg" controls>
This is fallback text to display if the browser
does not support the video element.
</video>

... it would appear that movie.webm is in the same folder as the webpage that I'm viewing. Doesn't this cause a security concern, whereby anyone could download the file as opposed to just watching it? Is there a way to prevent such an action? (Same question for the <audio> tag.)

This seems relevant when discussing this technology, because I cannot imagine that a site who streams audio/video would want those files to be downloaded. So in the case of <audio> and <video>, what prevents a user from stealing the files themselves? — Timneu22 · talk 14:56, 13 January 2011 (UTC)

Where is the security concern? this is only a design problem, but if you are a technic-known you will know everything you can watch on the screen can be captured... flash is also only a container for two (or three?) different video containers like h264. that means this is also not secure for downloading. where is the problem now? mabdul 17:36, 13 January 2011 (UTC)

I'm aware that anything on a screen can be captured, but not by most people. But if Netflix uses <video>, or Pandora uses <audio>, won't I just be able to browse to that directory and still the file? Right now it's not so easy. I'm wondering about the security of these tags. — Timneu22 · talk 18:22, 13 January 2011 (UTC)

You could also steal all the images off a web page, or download the HTML code of every publicly accessible page on the site. HTML has always made that easy. I could easily download webpages from Netflix and create my own site that looks exactly like Netflix. I can't use that technique to steal the video though, because they've chosen not to use HTML5 video. If you want DRM, HTML5 video isn't an option. Reach Out to the Truth 20:21, 13 January 2011 (UTC)

Ooooh. (I'll assume that works for <audio>, too?) I think this is worth mentioning in the article, then. I do web development, and I was led to believe that <video> and <audio> were the greatest things ever. If there are limitations about DRM and such, I'd think a sourced statement in the article is worth mentioning. — Timneu22 · talk 20:38, 13 January 2011 (UTC)

And here are some:

• http://gizmodo.com/5461711/giz-explains-why-html5-isnt-going-to-save-the-internet
• http://gigaom.com/video/netflix-no-plans-for-html5-video/
• http://www.pseudocoder.com/archives/why-html5-video-wont-replace-flash

Some sources... probably should have googled that before starting the conversation! — Timneu22 · talk 20:46, 13 January 2011 (UTC)

I don't know what do you want to tell ME? Nobody told that HTML5 will rescue the WEB (not the INTERNET); I doesn't matter if any company doesn't plan to support html5 or uses any other technology nor should HTML5 replace Flash.(they have different working areas...) maybe flash video (since everybody is able to install an extension/addon and download the video without restrictions). mabdul 21:40, 13 January 2011 (UTC)

Not sure what you're asking or saying, or why you're replying to me specifically. I think it's notable that HTML5, while a "new" technology allowing videos/audio to be played, lacks significant features that prevent major video websites from using it. — Timneu22 · talk 21:44, 13 January 2011 (UTC)

The mayor video site is/will be using it: Youtube. The pirate Bay, Archive.org, Wikipedia and others are planing or do support HTML5 v/a. Nobody told that this(v/a) is a new technology. It is firstly standardized by all major browser vendors and best thing is that these specs are open and free! That is the new. For Flash(for example) you have to pay! And DRM (thats the only "missing" feature) can be added later if these basic specs are working. mabdul 21:51, 13 January 2011 (UTC)

Well observed, this is the whole point! In fact, content providers who think they can "protect content" from being consumed in every way consumers please, are wrong.

Theorem: Every content protection mechanism is a denial of computing freedom.

Proof by contradiction: A user who has control over his own computer (a necessity of computing freedom) can make his computer do anything it is physically capable of, including modifying his computer's processing of "content".

Corollary 1: As long as anyone can control computers, no content protection mechanism can protect, they can only obfuscate/obscure.

Corollary 2: Content protection can not be contained in Free Software, since that would reveal it. And if it did, it would be modified to the benefit of the consumer and be pointless.

Given that it should be possible at all to use Free Software, we can not allow content protection!

129.241.30.137 (talk) 01:32, 14 January 2011 (UTC)

Google Chrome version 10 and H.264

Hello, I'm a little confused as to what to do. Multiple sources ([2] [3] [4]) are reporting that Google Chrome version 10 does not have support for H.264. In other words, in a recently released Google Chrome, H.264 support was removed. However, when I run the html5 test and the microsoft video format support page in google chrome 10 on my home machine (linux or windows) I see support for Html5. I have a hard time going with the sources when I see such clear evidence to the contrary. Suggestions? ~a (user • talk • contribs) 05:16, 22 March 2011 (UTC)

Google has announced removal but hasn't carried it out yet as of version 12. Sources that claim removal right at the time of announcement are wrong. Hsivonen (talk) 14:58, 2 May 2011 (UTC)

They sure are. I just set up an h264 in mkv container and chrome played it. This needs to be clarified that it has not been removed yet. — Preceding unsigned comment added by 24.141.219.11 (talk) 22:49, 13 January 2012 (UTC)

Missing: Overview of supported features and comparison to Flash/Silverlight/Java

This article only focuses on the debate around video codecs and formats. What's sorely missing is an overview which lists features that explicitly ARE supported and features that are missing but present in proprietary web app runtimes such as Silverlight, Flash and Java. For example: RTSP straming, HTTP adaptive streaming, live streaming, DRM protection, client side playlists, custom transport/format extensibility - these are all examples of standard media features that are missing from the HTML5 spec. Why is nobody talking about these? —Preceding unsigned comment added by 67.40.16.99 (talk) 21:08, 25 March 2011 (UTC)

Because we do not live in Redmond, Washington. Seriously, though: if you have a conflict of interest, you might want to make it known. Regarding the content of your message: a few of these things are not discussed here because they are largely unimportant. DRM as an example: users are not clamoring for more DRM in their open standards. How would DRM in an open standard even work? I'm pretty sure DRM is dependent on a certain level of secrecy regarding how keys are passed around. This seems incompatible with an open standard. ~a (user • talk • contribs) 09:09, 30 March 2011 (UTC)

Removing the "Others" column form the format table

For all practical purposes, the formats that are of interest in the context of HTML5 video are WebM, Theora and H.264. Other formats aren't really used in practice because of worse interoperability than the three formats specifically mentioned. I think the "Others" column in the table doesn't provide any real value to the reader and removing the column from the table would make the article clearer. Hsivonen (talk) 15:02, 2 May 2011 (UTC)

Pre-installed Flash plugins

"...many web browsers have Adobe's Flash Player pre-installed...". That's a bit misleading. Most browsers don't have the player pre-installed. I've reworded based on the page for Adobe Flash Player. —Preceding unsigned comment added by Laptcd (talk • contribs) 17:14, 23 May 2011 (UTC)

Future events

Several editors (generally IPs) constantly add to the table the "X planned" (namely h264 support for Firefox and h264 removal for Chrome). As no dates are settled, such additions boldly violate WP:CRYSTAL. Please note only the events that already occurred. — Dmitrij D. Czarkoff (talk) 13:44, 8 April 2012 (UTC)

What about ads?

If <video> becomes like <img> and say everyone quit using Flash; would end users have a "digital right" to be able to stop an HTML5 video advertisement from downloading with a context menu? — Preceding unsigned comment added by 184.21.215.174 (talk) 07:44, 6 September 2012 (UTC)

Correct. The fundamental openness underpinning every web standard (at least those made by IETF, W3C, etc) is meant to protect your right to "control your computing" as Richard Stallman would say, and "own your data" as Håkon Wium Lie would say. That is the rule of the web – no one did ever have the right to dictate how you consume the data going through the wire in the first place. Flash is a contamination in that respect.--84.209.102.192 (talk) 18:43, 15 September 2012 (UTC)

Complex table

Is it really necessary to list the latest releases of each browser on each OS? It doesn't really seem all that relevant to the topic to me, but must require constant updating. Also, I think Safari for Windows should be removed, as this is no longer supported by Apple. Are Web, Konqueror and Chromium really relevant to the debate? The market share of these three, even combined, is tiny. MatthewHaywood (talk) 11:14, 11 September 2012 (UTC)

No, these are not the latest version numbers; they signify which version the shown support is relevant for.

Minority browsers are relevant for showing broadness of support for HTML5, and killing the portability incentive/myth of using Flash.

Market share: I wouldn't believe such statistics, unless I could verify their classification of the user-agents in question. As a Konqueror user, I am so fed up with being incorrectly recognised as safari user.

Complex? Rather oversimplified, I woud call it, because you can't generally say «this browser supports that format». It depends on the codecs shipped with the operating system more than anything else, which this table fails to convey.--Anordal (talk) 17:49, 15 September 2012 (UTC)

I specifically added a plot with respect to market shares to show the formats availability per user, not per browser type. BTW Konqueror doesn't get identified as Safari. — Dmitrij D. Czarkoff (talk•track) 18:45, 15 September 2012 (UTC)

The Safari Mac OS X row appears to be completely bogus information that is meant to apply somewhere else. The manual installation note for instance, or the lack of support in the h.264 column referencing a WebM citation. Dasil003 (talk) 12:44, 8 November 2012 (UTC)

Firefox vs. h.264

FireFox 3.5+ on Windows 7 with installed h.264 plugin support h.264 video well, including most common method to play (tested on http://www.html5rocks.com/en/tutorials/video/basics/)

Mozilla will add H264 for Firefox OS and Fennec: "Android 4/4.1: hardware and software decoder support for h.264 video" https://www.mozilla.org/en-US/mobile/17.0/releasenotes/ In futur, it could available on Mac OS, Windows 7 and Linux (with gtreamer-bad-plugin): https://hacks.mozilla.org/2012/03/video-mobile-and-the-open-web/ https://bugzilla.mozilla.org/show_bug.cgi?id=794282 https://bugzilla.mozilla.org/show_bug.cgi?id=799318 — Preceding unsigned comment added by 86.64.71.89 (talk) 13:58, 16 November 2012 (UTC)

Its been possible to enable h.264 in firefox on linux since version 14. You just need to build it with --enable-gstreamer. But the official builds have not enabled it yet. 194.36.2.117 (talk) 14:17, 18 June 2013 (UTC)

Browser support

Please do not add unsupported OS with any web browser which are not real present on market, like FireFox on unsupported OS X 10.6 with market share below 0.01% in this combination. On market are hundreds web browsers and thousands in combination with OS versions, but most of them have unmeasurable market share. Goal of this table is not imagine every possible combination of web browser and OS version, but only combination with appreciable share. — Preceding unsigned comment added by 217.30.64.202 (talk) 19:35, 10 September 2014 (UTC)

HEVC on Android

@LiberatorG: changed the table to say that HEVC is not supported on Android, saying "HEVC in Android Browser HTML5 video does not work for me. Ref is for OS support, not browser. Please cite and specify browser version if available." But the ref https://bugs.chromium.org/p/chromium/issues/detail?id=460703 was indeed for the browser; it says "Playing plain HEVC mp4 files in Chrome/Android/Nexus5 works fine, e.g. this one: http://www.bitmovin.net/hevc/720p.mp4".

I tested on my own Nexus 4 phone, and it plays directly linked HEVC files as well as HEVC files inside a HTML5 video tag. Test case: https://www.thuejk.dk/hevc.html

While I acknowledge that I don't have a really good reference for hevc working on android, nor know which versions it works on, the current blanket "no" is obviously incorrect. Thue (talk) 09:25, 22 March 2016 (UTC)

@Thue: HEVC is supported by Android (in 5.0). The row of the table in question is not for the OS, it is for the Android stock browser from AOSP that was the default browser at least in Android 4 and earlier. I don't think it has a name other than "Browser", which unfortunately makes it difficult to discuss. I know some newer devices with Android 5 have changed the default browser so it can't even be called the default browser any more. The link mentioned above is a user's side comment in a bug report that is talking about a completely different browser. Did you test with the AOSP stock browser? I could not find any reliable source that indicates that HEVC is supported in the AOSP stock browser, and found many claims that it is not supported, but if you find one please add it along with the version number where it is supported. (You had claimed "Yes", implying that it is supported in all versions, but I have verified that that is not accurate.) LiberatorG (talk) 18:23, 22 March 2016 (UTC)

Oh, also http://www.bitmovin.net/hevc/720p.mp4 is 404 for me. LiberatorG (talk) 18:51, 22 March 2016 (UTC)

@LiberatorG: I tested HTML5 video/HEVC in a a stock browser on a stock Nexus 4. It does indeed work for me. The default browser on my Google-branded Nexus 4 calls itself "Chrome", so I assume that is indeed what the bug report talks about, not "a completely different browser" as you say. And as I linked above, https://www.thuejk.dk/hevc.html is a html5 video hevc test case.Thue (talk) 21:15, 22 March 2016 (UTC)

@Thue: I mean that the AOSP browser named "Browser" (package name com.android.browser) is based on the AOSP code https://android.googlesource.com/platform/packages/apps/Browser/, whereas the Android Chrome browser is based on the Chromium code, so these are completely different browsers. However because the Chrome version numbers are much larger, and Chrome supports all of the video formats supported by the AOSP browser, there should be no technical issue with using the same row for both as long as a version (not "Yes") is specified and it is clear whether each claim of support includes the AOSP browser.

My larger concern, however, is that every remotely official source I have found implies that HEVC is unsupported in Chrome, except for Chromecast. https://www.chromestatus.com/features#video and https://www.chromium.org/audio-video do not list HEVC at all, and various other sources such as commit messages claim no support in Chrome except for Chromecast. Even the bug report that you linked was closed with the comment "We have no plans to support HEVC in Chrome or Chromium". It is interesting that your test nevertheless appears to work on your device, without any commit that appears to have intentionally enabled it, which raises the question of whether that is truly supported, or just experimental, perhaps with issues that cannot easily be fixed, or only enabled on some devices or for some restricted purposes. That might make for an interesting blog post, but goes against WP:OR. LiberatorG (talk) 10:56, 23 March 2016 (UTC)

Well, the "no" you wrote is also against WP:OR. Thue (talk) 11:05, 23 March 2016 (UTC)

The official pages that list the supported codecs are a reliable source and they do not include HEVC. LiberatorG (talk) 11:10, 23 March 2016 (UTC)

Should we list plugins in the table

Regarding this edit (was undone and then redone by me).

I don't agree that we should list plugins in this table. If we did, we could fill all fields for the Internet Explorer, Safari, Konqueror and Web browsers, with "Via a plugin", since (for example) the VLC plugin supports all listed video formats.

OpenCodecs (for Internet Explorer on Windows) and Xiph QuickTime Components (for Safari on macOS) are a bit different, since they provide the codecs at the OS-level, but maybe they should be removed too.

Lonaowna (talk) 10:20, 15 September 2017 (UTC)

• Support (remove "via plugins"). Hi. Lonaowna seems to be talking sense. Of course, listing plugins that have a Wikipedia article too, in a separate section, is permissible by WP:NOTDIR. —Codename Lisa (talk) 16:36, 15 September 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on HTML5 video. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100813023244/http://www.w3.org/TR/html5/video.html to http://www.w3.org/TR/html5/video.html
• Added archive https://www.webcitation.org/66FyLFzqr?url=http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-December/013135.html to http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-December/013135.html
• Added archive https://web.archive.org/web/20110321150357/http://labs.opera.com/news/2010/05/19/ to http://labs.opera.com/news/2010/05/19/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:06, 27 October 2017 (UTC)

VP9 in MP4

I wonder, why people think that VP9 in MP4 is not supported? Why need to undo my edit of the article? — Preceding unsigned comment added by 93.153.138.62 (talk) 09:13, 2 November 2017 (UTC)

Hi.

I wonder what makes you think it is supported? Could you please kindly enlighten us?

Best regards,
Codename Lisa (talk) 09:11, 3 November 2017 (UTC)

Hi.

Were you, by any chance, banned from google? Just wondering.

Everybody knows that it is supported. It is common knowledge. — Preceding unsigned comment added by 93.153.138.62 (talk) 08:27, 8 November 2017 (UTC)

Hello

The burden of evidence is on the person who claims something as fact. Everyday, hundreds of people make wild claims in Wikipedia. Most of them are their mistakes. A small percentage are outright lies. A yet smaller percentage are true.

Most publishers ask for money in order to print what you think is true. Wikipedia asks something else: Proof, in the form of reliable sources.

Best regards,
Codename Lisa (talk) 09:27, 8 November 2017 (UTC)

So, web-sites are not proof enough for you. https://www.google.ru/search?q=vp9+bmff

Then probably we should wait for book to be published on this topic.

At least now I understand why this article is outdated. — Preceding unsigned comment added by 93.153.138.62 (talk) 10:26, 8 November 2017 (UTC)

Hello again

Some of your search results demonstrate attempts to implement VP9 in MP4. I can certainly open www.chromestatus.com/feature/5762080762232832 in a couple of web browsers and see if that browsers supports VP9 in MP4 but if someone asks me for a proof that I indeed did so, in the form of a reliable source, I have none. Someone who has carried out this test must first publish the results, then we can cite that publication.

Best regards,
Codename Lisa (talk) 12:08, 8 November 2017 (UTC)