[quote]Support: here is a performance comparison of the latest iteration of the WebM encoder hardware, showing also previous versions and a h.264 encoder for comparison.

http://blog.webmproject.org/2011/11/time-of-dragonflies.html%5B/quote%5D

I hope you realize that the comparison you linked to compares ENCODER quality between two decoders (H264 and WebM) made by the same company? It says nothing about the abilities of WebM as a codec.

Try this one instead:
http://x264dev.multimedia.cx/archives/377

Name 1 useful, headless, x86, binary-only linux application, that does not have a viable alternative that can be easily ported to ARM...

You say 'plenty of software' and 'large amounts of software that can now be easily ported', but I'm genuinely hard-pressed for even a single example that proves you right.

[quote]Come up with some studies showing people's reasons for buying an iPad and I'd pay attention. But just saying, "They sold more of them, that means that they love X 'feature'" isn't necessarily true.[/quote]

Fine, then go lookup customer satisfaction numbers and return rates for iPads/iPhones vs Android tablets/smartphones. Or are these figures also somehow not indicative of the fact that people buy Apple products because they happen to like them, in various ways?

You are posting this as if there's some kind of paradox or contradiction in that... There isn't...

Just look around you and find out different people buy different stuff for different reasons. Many bad products and services are succesful, even though they are competing with good products and services. Price is often (but not always) the explanation.

In the case of Android, it's pretty obvious why Android is outselling iPhones, it's because there are literally hundreds of times more Android phones than iOS phones, and the vast majority of them is bought by people who either don't know about smartphone OS's, don't care about it, or simply don't want or cannot spend the money on an expensive high-end phone.

If you sincerely think 'Android outsells iPhones' implies 'Android is better than iOS', you are delusional. That would mean each and every crap Android phone you get for free in a BOGO deal is better than the iPhone, and that's why people get them. 90% of Android phones sold = utter crap, 10% = good phones. Just go ahead and look up some customer satisfaction rates and return statistics.

The original point was people buy more Android phones because they are better, but stating the fact that the iPhone 4 and the 3GS are the two top-selling smartphones on the market, your conclusion is that's because with iOS you only have 2 hardware options? So if Android is 'higher quality' (even though customer satisfaction numbers say otherwise, and sales of individual handsets don't seem to support that assumption), how come only 2 phones are outselling a few hundred different ones? Nice logic you have there, you are basically stating that -1 + -1 = 3, or something similar.

Also, since when does the typical Slashdot reader think 'sells more' implies 'is of higher quality'.

It's fascinating to see how flexible typical geek thinking is, when it comes to defending minority opinions.

Actually, in the US the fastest selling handset is the iPhone 4. The number 2 fastest selling handset is the iPhone 3GS. The former is 14 months old, the latter 26.

Nice try though...

Nice try, but the iPhone batteries don't actually noticeably degrade in 12-24 months, and even after 2 years battery life is still much better than the vast majority of other smartphones. If you really insist on keeping an iPhone for longer than 2 or 3 years, you can always replace the battery or have it replaced cheaply by the way, the warranty would have expired by then anyway.

My 2 year old 3GS still gets around 48 hours on a single charge if I don't use it a lot, and even with the heaviest of usage it never runs out of charge over the course of a single day. Many people I know with spakning new Android phones carry around a cable or charger all the time because they sometimes don't even make it to a 10-hour work day, with their 'replaceable batteries'.

Others have already predicted VP8 would run into patent issues.

Anyone who knows even the least bit about video codec technology can tell you that it's virtually impossible to design an advanced video codec that does not infringe on any video coding patents, which isn't surprising if you consider the technology involved is decidedly non-trivial, and took over 3 decades to develop. H264 is currently the most advanced standard for video coding, but it didn't materialize out of thin air either: it simply builds on the concepts you'll see in MPEG 1, 2, 4 and so forth.

The only codec I can imagine that does not violate any H624 patents would either be incredibly crappy, or downright revolutionary. I know for a fact that VP8 is not the latter.

Which is exactly why you should leave the science part of the work to scientists, have them prototype a solution, work it out along the way and improving it, until it meets its scientific requirements. Then, at set points, you should leave it to the software engineers to productize the prototype based on the set of scientific requirements currently implemented, and keep those fixed as long as possible. If the target is moving, settle on a release schedule for the productized code that allows planned functional updates. This way the science work and the software engineering work can be done independently and both sides can be happen.

In reality, this often means you will end up with 2 implementations, which implies you need capable software engineers who know how to do regression testing and qualification of the software probably.
Where I work, we have physicists, mechanical engineers and construction engineers prototype solutions in Matlab, they love that tool, they can try out new ways of solving their problems quickly, prototype the hell out of them, graph and plot the results, etc. It's a great tool for scientists really. When it comes to productize the resulting solutions (simulation models, mainly) and integrate them in the (extremely expensive) hardware they will be used in, the software engineers (me, amongst others), get a functional specification, a test specification and a test report, all based on the QA'ed Matlab code, and we re-implement it in the target language best suited for the application (C++ or Python, mostly). This usually involves isolating the 'meat' of the algorithm and designing a maintainable, flexible software architecture around it, that allows deployment for other applications, adding scripting interfaces on top of the models, better regression testing, etc.

It may sound like a stupid idea to keep 2 implementation of the same idea around, but it's not, trying to productize a moving target and having two sides of the problem implemented in one piece of code will take more time, more risks, and more annoyances between the involved parties.

The way we solved it for my job works great for everyone, the only annoying thing here is middle management, who like to think they can do a better job at both the science and the software engineering work, and sometimes decide we 'have to have to productize the Matlab code', we 'have to have 1 implementation only', or 'we don't need to allocate a lot of time productizing because if the functionality is done, translating it to a usable software component is easy'. :-/

So what's the big difference between side-loading on Android and side-loading on a jailbroken iPhone, that you would want to 'not count jailbreaking the iPhone'?

Both involve messing with the device and software in ways that are outside the comfort zone of typical smartphone users, but neither are difficult or invasive enough to scare off people who don't mind doing it. I don't see the difference here, but I guess it's fair game to use a sliding scale for comparisons that involve Apple these days.