Talk:HTML video

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)

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)