Slashdot Mirror
Vimeo Also Introduces HTML5 Video Player
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."
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.
"The worst tyrannies were the ones where a governance required its own logic on every embedded node." - Vernor Vinge
Actually, I'm pretty sure porn went for HD-DVD. So it's not always the right indicator.
https://bugzilla.mozilla.org/show_bug.cgi?id=422540
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.
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
here's the thing - something that's genuinely new and required real effort like H264 to develop, patenting it is a valid use for the patent system. and if you look at the licensing terms for h264 is insanely fair and cheap - your looking at only $100,000 for a service with 1,000,000 subscribers, and thats only if your a commercial entity. i dare say if your running a website that has a subscription of over a million people you can afford $100,000 for the core technology that under pins your operation. if you can't, Your Doing It Wrong.
If you mod me down, I will become more powerful than you can imagine....
lol. i'd never heard of daily motion before, so it's chances of rolling youtube are slim to none, especially based on the back of h264 vs theora.
If you mod me down, I will become more powerful than you can imagine....
I think you mean
Now, if only the stupid h264 codec would be freed !
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.
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.
Portable versions of Firefox, GIMP, LibreOffice, etc
Sure.
http://www.effectgames.com/effect/games/crystalgalaxy/
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
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.
I am TheRaven on Soylent News
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.
I am TheRaven on Soylent News
ActionScript 3 is one dialect of ECMAScript as is Javascript and JScript. Nothing really to do with Java.
- Raynet --> .
Dilbert RSS feed
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.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
> 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).
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.
Hey KID! Yeah you, get the fuck off my lawn!
> 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.
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]
> 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.