Vimeo Also Introduces HTML5 Video Player 369
bonch writes "Following in YouTube's footsteps, Vimeo has now introduced its own beta HTML5 video player, and like YouTube, it uses H.264 and requires Safari, Chrome, or ChromeFrame. The new player doesn't suffer the rebuffering problems of the Flash version when clicking around in the video's timeline, and it also loads faster. HTML5 could finally be gaining some real momentum."
Branding over functionality... (Score:5, Informative)
It seems that both Youtube and Vimeo have both chosen to use their own custom controls, and disable the default controls native to the user's browser.
That wouldn't be such a big deal, except for the fact that full screen mode can currently only be entered using those default controls (making full screen mode available via a scripting api is considered a security risk, and thus discouraged by the HTML5 spec). So they're sacrificing that functionality at the alter of branding.
Re:Branding over functionality... (Score:2, Informative)
I'm going to have to put the blame on the browsers for not implementing a "double click the video to go fullscreen" behavior or some sort of key binding. Sites shouldn't have to refrain from branding just to allow the user to go fullscreen, the browser should always provide a method for the user to do it.
Re:This may not be an apt analogy, but (Score:5, Informative)
Re:Excellent. (Score:5, Informative)
https://bugzilla.mozilla.org/show_bug.cgi?id=422540 [mozilla.org]
They are working on a Gstreamer backend for the video tag, and that will provide support for h264. From skimming the comments, it seems that there is a working but slow patch for 3.5, which is yet to be updated for 3.6.
Re:Excellent. (Score:1, Informative)
Must be a typo. I think you'll find most seem to be pretty favourable to H.264. Unless that is you could provide a single link that shows a Theora video with higher quality than H.264 at the same bitrate?
I could give you about 10 that show otherwise. here's one [osnews.com]
Re:Here that wooshing sound, Firefox? (Score:4, Informative)
Re:Daily Motion (Score:3, Informative)
Re:Excellent. (Score:5, Informative)
I think you mean
Now, if only the stupid h264 codec would be freed !
H.264 (Score:5, Informative)
Everytime this topic comes up I am amazed at how many people think that it's somehow Mozilla's fault that Firefox doesn't support H.264.
Repeat after me: H.264 is NOT FREE, not by a long way. If Firefox included H.264 support then Firefox would also NOT BE FREE. It would be illegal for most of us to distribute a copy.
Cost for Firefox H.264: $5,000,000+ per year (Score:5, Informative)
The problem with H.264 is both its patent status and the licensing cost. The patent means that it can't legally be used in software licensed under the GPL/LGPL 3.0 in countries like the US. So, Mozilla would have to add a closed-source component to Firefox for it to be able to work.
But the other problem is the licensing fee. Firefox ships so many software units that it will hit the enterprise cap for H.264 licensing every year. In 2006, that cap was $3,500,000. In 2007 it went up to $4,250,000. In 2009 it went up to $5,000,000. In 2011, it is going to go up again. So Mozilla will have to pay out $5,000,000 (and climbing) per year, just to support this one video codec in a product that they give away for free. Their revenue in their last fiscal year was $78.6 million.
Is it really worth it to spend 6% of your total yearly revenue on the licensing fee for one video codec?
Apple doesn't care, since they already hit the yearly cap anyway (see: iPod/iTunes) so it's free for them to include it in Safari. I'm not sure if Google does (can't think which apps it would be), but they have the money to do it either way. Opera and Mozilla don't currently have this expense... and they can't afford it. Nor can any other upstart browser since once they hit 200k 'units' per year, they have to start paying $0.20 per download.
Re:Adobe... (Score:3, Informative)
Sure.
http://www.effectgames.com/effect/games/crystalgalaxy/ [effectgames.com]
Re:H.264 (Score:2, Informative)
But why?
Isn't that obvious? Because they choose not to use the system frameworks.
So instead of having one or two well supported codecs, you'd have a hundred and one that might work. You'd be back to the plugin-hell that online video was before Flash came along.
I don't see a plug-in hell if everyone is standardizing on h264. You might have the option to use one of several decoders, yes. And that's a good thing!
Anyway, it would not be Mozilla's problem. But it is if they simply refuse to play back h264 altogether.
Re:The problem with Directshow (Moz/Opera devs) (Score:4, Informative)
The main problem with this approach is that many DirectShow filters are written in such a way that they can only read from a local file, since the DirectShow framework makes this a lot easier than the "right way" of streaming input from a upstream filter
Now, admittedly, the last time I wrote any DirectShow code DirectX 8 was all new and shiny, but this sounds like complete nonsense. Writing a DirectShow filter is trivial. You just subclass the standard filter class and receive data on one of the pins. I wrote one that took data off any part of a DirectShow stream and chucked it across the network and a matching one that received it. I had absolutely no problems swapping in other CODECs. They all just took data from one pin and pushed it out on another.
Writing a DirectShow filter that can only read from a local file is a pain, because you need to implement support for all of the potential container file types. Writing one that fits with the rest of the architecture is trivial.
Security is a potential issue, but I'm not sure that GStreamer is any more secure. Both contain large amounts of code that can potentially house exploitable bugs. If you care about security then you should run the CODEC in a separate process with a pipe going in to it to provide the data and a shared memory segment for getting the rendered images out.
Re:Excellent. (Score:3, Informative)
No. The licenses for Chrome and Safari do not allow unlimited distribution. The H.264 licenses are capped per year, so Mozilla Corp. could easily afford to pay for an H.264 license for this year and then everyone who distributed FireFox would have a legal license as part of that. However, if they stopped paying, people who had received FireFox would then be unable to legally redistribute it. As Mozilla is distributed under three licenses which all permit redistribution, that would mean that anyone, like a Linux distribution, that distributed copies from upstream would be infringing.
I'm not sure if FireFox and Gecko require copyright assignment for patches, but if they don't then the Mozilla Foundation would also be violating the copyright of their contributors if they distributed it along with code that required a patent license.
Re:Adobe... (Score:3, Informative)
ActionScript 3 is one dialect of ECMAScript as is Javascript and JScript. Nothing really to do with Java.
Re:Excellent. (Score:3, Informative)
Re:Adobe... (Score:3, Informative)
He asked for an example of a game in HTML5. I provided an example of a game in HTML5. A simple transaction.
Ironically it's you who's left over bleating to yourself, working yourself up into a frothing rage over things that nobody ever said. You might want to check your caffeine dosages.
Re:Here that wooshing sound, Firefox? (Score:3, Informative)
> I consider over a year of warning with no implementation in production 'unprepared'.
You're assuming that the goal was to support H.264. That's not in fact a goal at the moment, because it's seen as detrimental to the future of video of the web (though of course beneficial to several big companies today).
Re:All hail HTML5 what a crock of shit (Score:4, Informative)
Box model, input model, floating model, version model etc. etc.
Think it through, then think through all of the kludges you have to come up with to make these work correctly then you will understand.
We had to wait for 5 versions of of HTML before we got an input type defined to handle things like numbers (floating, integer, fixed point), time, date?!
Or how about a property to mark an input element as required instead of either having to come up with some javascript to then ripple through the controls to see if they are filled in, this should be handled by DOM and refuse to fire the submit method of a form unless all the fields marked in such a way are populated.
How about a check box that actually is sent back in the post method to indicated that fact that it is NOT checked instead of having to write code that has to check if 1 of n check boxes are not there to figure out if the user decided not to check it.
Or how about that Text Area is not considered an INPUT tag. Seems to me it should be since it accepts, wait for it.... INPUT for fucks sake.
How about being able to float a DIV center and have text flow around it and conform to the DIV's margins, nope that don't work either.
The box model where changing the internal padding, essentially an internal margin, changes the size of the box and shoves everything around it all over the place or adding a border stripe changes the external size of the box, don't even get me started...
The list goes on and on and on. Get this shit fixed first the video will take care of itself.
Re:Here that wooshing sound, Firefox? (Score:4, Informative)
> They are aware of the issue but they don't have a production ready solution.
"They" (we) are in fact aware of the issue, and feel that H.264 as the "standard" web video format is in fact detrimental to the long-term health of the web and to Mozilla's mission (which is not to make a web browser; the web browser is a means to an end).
> they will eventually have to support all of the codecs in the HTML5 standard
The standard doesn't specify any codecs.
Re:Here that wooshing sound, Firefox? (Score:3, Informative)
True. Bad choice of words. I should have said 'supported by' instead:
"On October 17, 2007, the World Wide Web Consortium encouraged interested people to take part in a "Video on the Web Workshop", held on December 12, 2007 for two days.[10] A number of global companies were involved, submitting position papers.[11] Among them, Nokia's paper[12] states that "a W3C-led standardization of a 'free' codec, or the active endorsement of proprietary technology such as Ogg by W3C, is, in our opinion, not helpful." Ogg's codecs are licensed under the BSD open source license, and are therefore not proprietary in any accepted sense of the word. Apple Computer have also opposed the inclusion of Ogg formats in the HTML standard on the grounds that H.264 performs better and is already more widely supported, citing patents and the lack of precedents of "Placing requirements on format support", even at the "SHOULD" level, in HTML specifications.[13]
In response to such criticism, WHATWG has cited concerns over the Ogg formats still being within patent lifetime and thus vulnerable to unknown patents.[14] Such submarine patents may also exist for non-free formats like MP3 and H.264. Also, the AVC patent licensing policy is subject to change in a not-yet-clear manner.[15]
[edit] HTML5 turns neutral"
On December 10, 2007, the HTML 5 specification was updated[16], replacing the reference to concrete formats:
User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format.
with a placeholder:[17]
It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. This is an ongoing issue and this section will be updated once more information is available.[18]
Re:Excellent. (Score:3, Informative)
> I'm just wondering what makes the Firefox team certain they can write these codec
> implementations and players better than the teams who specialise in that field.
Nothing. That's why they're not writing the codec impl they're using; they're using an off-the-shelf theora decoder (though they've contributed a bunch back to it in the process of integrating it).
But the result is that the codec they're shipping they have the source for and have at least some people who can competently patch that source in the event of a security hole being discovered, while also sending the patch upstream.
As for the player... The player being used is pretty much off-the-shelf too, as above, but the method of feeding data into it had to be custom-written to deal sanely with HTTP, security restrictions in the browser, etc.
> no reason to believe that a volunteer for a browser project
I believe everyone working on the Theora support in Firefox was in fact a full-time employee whose job it was to make it work.
> I know Quicktime / ffmpeg / etc are all open to system flaws and attack, but what code
> isn't.
Sure. The question is what happens once such a flaw is discovered. If you're not Apple and you depend on Quicktime and a hole is discovered in Quicktime, what are your options? Have a security hole or stop playing videos until Apple patches it? The situation is, of course, better with ffmpeg.