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."
Now if only FireFox will get support.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I shed not a tear for you.
Better known as 318230.
That's the sound of you getting passed by.
I'm a total GNU fanboy most days, and generally agree with the moral move they are trying to make with OOG formats, but in this case it is a losing strategy. H264 video has gotten a momentum that is hard to break, similar to how MP3 got a momentum in the past. It has nothing to do with technical features, morals, licensing, or other commonly-argued things. Instead, it's about a critical-mass of popularity. H264 video the new pop thing, even in cases where people don't even know terms like "H264".
By not finding a way to make video work properly, Firefox is saying they want to be left behind. No, I highly doubt people like google or others will re-encode video into Theora. They will make the business decision that not only is it a lot of work, it's not necessary as firefox is supported with Flash.
If the Firefox people want to make a good moral stand with this issue, they should pull something similar to the crypto situation and make an "international" version. That version could serve as an embarrassment to the restrictive patent system, and a useful political talking point. At a minimum, though, they should simply remove all codec processing form the project, leaving that particular can of worms to an external project (gstreamer? embed mplayer/vlc/other? some new project created specifically for this purpose?).
I love firefox. I really do. So please don't choose to be non-player in the video arena!
Ce n'est pas une signature automatique.
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.
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.
Google recently acquired On2, makers of the Ogg Theora (aka VP-3) codec which was released into the public domain and then taken over by xiph.org.
On2 have codecs VP-7 and VP-8 which have equivalent (if not better) quality than h.264.
It would not be surprising if Google made those codecs available, since they aren't patent-encumbered, and Google is heavily invested in HTML5 --and likes open standards.
This would be the ideal outcome. h.264 is a really bad option.
Look, ditching h.264 is simply not going to happen. there are way too many hardware devices out there that do h.264 and no ogg. All I'm hearing is bitching from the firefox camp about how they're not going to support it for reason X rather than looking for a solution to the problem.
Simply not supporting h.264 is an option, sure. I just don't think its going to end well for firefox.
AS to host code not being exposed to the web... run it with least privilege in a sandbox. My bet is that any copy of theora embedded into the browser is exactly the same reference code as used else where in any case (and if its, not, then its not as well tested...), so that point is pretty moot.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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
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
Because HTML5 + VIDEO tag draws people away *from Flash* and *into an open standard* that can be found everywhere.
What Microsoft would have liked would be, drawing people away from Flash and *into one of their own proprietary* technology, marketed as much better.
The core strategy of Microsoft is not just killing random IT companies for the fun of it (although it's not always obvious), but killing other companies in order to get bigger themselves in the process.
Silverlight is their optimal solution to lock more customer in Microsoft solutions.
HTML5 is their nightmare.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
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!