HTML5 'unhinged from reality,' say Javascripters Javascripters are trying to rescue HTML5 from video junkies and hypesters, saying the term is being misused - just like AJAX and Web 2.0. Endorsements by Apple and Google for the as-yet-unfinished HTML5 have turned this next iteration of the web's mark-up spec into the buzzword of the moment, and according to blog post from …
Big backtrack, which seems to have deliberately been ignored by the media...
http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx
"In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows."
From a developer's point of view the whole video thing is really quite unimportant, it's just another tag. In the end HTML 5 is (hopefully) just an improved way of displaying various types of content. The major players will fight over which codecs to use and we'll just wack in the video which our employers or clients request - much of which will probably still be in Flash. No big deal.
(Webm is not a codec; it's the Matroska container format renamed. VP8 is Google's codec.).
Adobe Flash built in to the "open" Google platform? I'm no expert on this stuff, but it's obvious to me what must be going on here. Google and Adobe are trying to incorporate elements they control into the open web. They want to guarantee a free lunch in perpetuity, as Microsoft did. Youtube is the lever, and Adobe has something else Google wants.
ANY video codec is going to fall foul of patents. There are at least hundreds of patents and numerous companies have patents in the H264 patent pool, not just MS and Apple. Many of those patents will apply to VP8 and Vorbis. If they gain traction as codecs, a patent pool will appear for them too; no different to H264.
Google says VP8 is not patent encumbered, but they are lying. They don't indemnify users of "free" VP8 code against patent litigation (as Microsoft does for PC makers using technologies included in Windows), and anyone who implements VP8 automatically loses their license to do so if they have a patent in a VP8 patent pool. (Google: "we're going to steal your ball, but you can play as long as you agree it's our ball now")
With no hardware acceleration, VP8 is a non starter for mobile. But Google can encode Youtube in a proprietary extended VP8 with hinting for hardware acceleration, get control of licensing hardware decoding. The "free" obfuscated C software codec will still work jerkily, but your battery will be flat. iPhone will be forced to take VP8 and Flash. Android phones will in practice get hardware decode before iPhone. Wintel PC versus Mac re-born as Android/Chrome gadget versus iGadget. Apple ground down into irrelevance again.
Adobe has been working on hardware accelerated Flash for ARM for several years (no result yet). Can you see what's going on here? An evil pact to lock a Google controlled VP8 and an Adobe controlled Flash into the so-called "open web". Google don't care that VP8 is patent encumbered, as long as they are in control. Whatever the license fees are, they'll be slapped onto the advertising charges and the handset costs - why would Google care.
And the trigger for all this? Apple's App store. Even Apple were totally shocked by the way users and developers forsook the open web entirely and dove into the proprietary app store. And what that meant to Google was that their search ad monopoly on the web wasn't going to automatically extend to mobile.
Paradoxically, the only company on the planet that seems willing to compete on merits is Apple. None of the others even wants to show up to a fair fight. This has been going on for so many years it's getting embarrassing.
I thought my eeePC was unable to handle playing HD video. Certainly if I try playing HD in YouTube, it stutters (720p) or crashes the browser (1080p). Downloading the file (720p version) and playing it in VLC fails. And VLC is the only thing I have that recognises HD content from Youtube as an actual video file.
Flash forward a few months. I have a video file that looked really good on-screen. An XviD, an astonishing 1280x720 - higher resolution than the display itself.
It might be all whoopee-doo to have modern more efficient codecs which use less bandwidth, but given that our video is increasingly available on lower power mobile devices, perhaps there's life in H.263 and "lesser" codecs yet?
My problem with HTML 5 is that it seems to just be adding a whole bunch more tags... tag soup was what HTML 5 was meant to prevent.
Doesn't look like happening as far as I can see. Everyone's just banging on about the new <video> tag... big woop. How about just standardising the use of the <object> tag with type="video" or something. Could be a bit more extensible. We're going to end up with more sites that are all over the shop standards-wise... sites written in a horrible concoction of HTML4, XHTML1 and HTML5 tags.
Be great if there was a brand new strict standard, non backwards compatible, making great semantic sense. A browser either supports it or not. Like a sort of XHTML 2, that would be good. Oh.
Yeah you're right. Thinking about it, a video tag is a good idea from the semantic standpoint at least. However as a developer I'm still worried about the mess. And some shocking browser-specific video UI implementations we'll see. Eg: in IE I can just see it being a cut-down WMP interface like when people used to embed wma/wmv in web pages.
It's a real shame XHTML 2 has sort of died. Having both XHTML2 and HTML5 maturing at the same time would have offered a bit more choice.
A start from scratch non-backwards compatible approach with only a strict DTD and a real modular approach would have been excellent. I would have used it anyway.
There were plans for an XHTML 2 standard which would've been incompatible with HTML 4 and XHTML 1.1, but that was cancelled last year at about the same time as HTML 5 was announced. http://www.w3.org/2009/06/xhtml-faq.html
I think a fresh start would've help get rid of some of those tags that got added when Netscape were competing with Microsoft - such as <marquee> and <blink>.
"How about just standardising the use of the <object> tag..."
Gah. The over use, mis-use, and abuse of the <object> tag was the whole problem, usually combined with half-assed plugins. No thanks. The <video> tag makes perfect sense, to go along with <text> and <img>. Now the question is whether the purveyors of half-assed plugins will try to foist them on us anyway. (Of course they will!)
month and you'll start to see job ads wanting 2 years plus experience in HTML5, just like they were when C# came out.....
And another month after that, big companies will be screaming at the government to bring in some people from overseas because 'british workers dont have 2 yrs experience in HTML5'
I could be more cynical, but it would be hard work
H.264 is not inside anyone's "proprietary layers." There is a thriving H.264/AVC open source community. H.264 is a fully documented, open spec. Anyone can write a codec to the spec. Yes, it is patented, but that's par for the course with media formats. You can't get around that. Quit acting like H.264 is a closed technology. It isn't. It's a damn standard.
And Jobs didn't threaten anyone. He just said what everyone else has been saying for years. The world of patents in the U.S. is convoluted. Anyone making any type of media format or codec, regardless of what license it is relaeased under, is potentially infringing on patents and will become a target for patent trolls. You can thank the USPTO for that.
Your Open Standard is open provided that you can prove that your codec (specifically the encoder part) has not been distributed more than 100,000 times in a year. Once this has happened, someone has to start paying license fees to MPEGLA (see the license at http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf). This is regardless of how it is distributed (direct download, torrent, viral spread). I believe that the important term here is 'branded', which will identify a particular implementation of the encoder for license purposes.
They will almost certainly come after the project owner(s) on SourceForge or whatever repository they have used, to collect.
Anybody engaged in such an "Open Source" implementation of an H.264 encoder, once it hits 100,000 copies in a year should be prepared either to disappear, or fork out large amounts of cash if their code becomes popular.
This means that although the writers may consider it open, MPEGLA almost certainly don't, and have the right to collect or prosecute in the US.
Of course, it may be possible to have an open source decoder, and make that a separate product from the encoder. This would enable the decoder to be downloaded for personal use as many times as needed, while being able to control the number of people using the encoder. The onus would still remain with the project owners to track and if necessary limit the number of uses of the encoder.
Additionally, it is possible that if you host the project in a country that is not encumbered by software patents, you may just be able to evade the US legal system, but you had better not be a US citizen, or resident in a country that has a 'special arrangement' extradition treaty with the US!
In re-reading the license (link in my last update), I suddenly noticed the following in the licensing costs section.
"For (a) (1) branded encoder and decoder products sold both to end users and on an OEM
basis..."
and also
"For (a) (2) branded encoder and decoder products sold on an OEM basis..."
In both cases, the operative word is "sold". Does this mean that an H.264 codec *given away for free* escapes this licensing condition?
If it does, then this gives the Open Source community a get-out-of-jail-free card.
Of course, it still leaves the media providers conditions in place.
Ignore JavaScript and the people who write the trojan-vectoring boil on the backside of the body I.T. Their oft-witless code shows the worth of their views.
"The core of HTML5 is less interesting and actually invisible to the end user."
Would that the nitwits who now load up the likes of Amazon's front page with worthless shiny - that does little to sell books (or anything else) but does ensure you'll have to trade in your machine years early on account of all the CPU cycles being sucked out by vampyric JavaScript - were invisible to the end user. maybe then an Amazon page would load in a timely manner.
Treat JavaScript the same way you treat disease-carrying mosquitoes - with extreme prejudice.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
