Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
More about the Chrome HTML Video Codec Change (The Chromium Blog)
Posted Jan 15, 2011 18:11 UTC (Sat) by JEDIDIAH (guest, #14504)
On the other hand, casting h264 in stone creates an entry barrier for everyone. It's not just about how there's a licensing quagmire with h264 but the fact that it is a format that pretty much requires specialized hardware acceleration.
Also, Flash is mainly about obscuring access to the underlying file. This is an area where HTML5 doesn't even really help anyways.
Posted Jan 16, 2011 15:59 UTC (Sun) by AndreE (subscriber, #60148)
There is a reason we want a standarded HTML and not the crapshoot we had before
Posted Jan 17, 2011 5:44 UTC (Mon) by JEDIDIAH (guest, #14504)
Publishers want to obfuscate content in a manner that makes it more difficult to deal with with generic tools (as opposed to "special plugins"). Any decent non-crippled video tools would have no problems with dealing with the sort of "chaos" you seem so fearful of.
It's the intentionally crippled and limited platforms that would have the most problems. This is a problem artificially created by the same people that created the earlier mess with exclusive single vendor proprietary codecs and the special plugins needed to deal with them.
This ultimately seems to be primarily about catering to the most restrictive and abusive system vendors in the industry.
Posted Jan 18, 2011 0:09 UTC (Tue) by AndreE (subscriber, #60148)
HTML5 addresses both the user and developer need to have a standardized video format for the web.
System codecs are NOT the answer because they give no guarantees to the content provider or the system user. There is nothing standardized about system codecs
HTML5 + WebM is the best answer. Of course, if HTML5 becomes split between HTML5/h264 and HTML5/WebM, then yes, we may as well be using system codecs
Posted Jan 18, 2011 0:27 UTC (Tue) by khim (subscriber, #9252)
It's the intentionally crippled and limited platforms that would have the most problems.
Yup. Things like TV sets, mobile phones, etc. You know, the devices which are actually used to watch video by non-geeks. Where hardware support is paramount because it makes tangible difference on your battery life or your monthly energy bill.
This is a problem artificially created by the same people that created the earlier mess with exclusive single vendor proprietary codecs and the special plugins needed to deal with them.
Sorry, but no. When you present a "non-crippled" platform which can play and encode HDTV video in realtime using less then one watt of power - we can start talking about "openness" and "pluggable codecs". Till then it's not an option. Because simple fact of life is: today there are more users of web-enabled mobiles then there are users of personal computers. Tomorrow (or, mre likely, in the next 2-3 years) these devices will start showing video - and what they'll support in hardware will be used on the Web.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds