Given that internet use on the iPhone is a flat $30 per month, this doesn't make AT&T any money.
But yeah, that'll happen... there are hundreds if not thousands of apps on Android that can live in the background and do something interesting via the net.
Multitasking is a natural concept... it's the single tasking in any OS that has to be learned.
Apple's been very good at teaching this as an acceptable limitation, to the point where the iPhonies defend this as some kind of intelligent choice, despite the fact their batteries last no longer than those of my Droid. I'm sure if Apple does introduce some kind of application multitasking, they'll be back to explain to us all why multitasking is suddenly A Good Thing, even though it wasn't in the past.
I think my Droid is as snappy as the best of the iPhone line, at considerably higher resolution. Your Nexus One goes a step beyond that. And yeah, there are Dalvik improvements on the way. Nothing like an OS tweak to affect every application... Palm did this, twice now, with their WebOS (most WebOS apps are writting in JavaScript!!).
Apple's playing catchup, or at least they ought to be, on a number of things. Multitasking is just one... how about screen resolution? Their treatment of the iPad, with its "run iPhone apps in the 480x360 naive mode" hack, suggests that they have no intention of supporting anything other than 480x360 anytime soon. That's fairly tragic... every modern top-of-the-line smart phone now has 800x480 resolution, or perhaps a bit higher.
Also, the rumor suggesting an "interface for switching between apps" does suggest some weirdness... how about background tasks? One of the main strengths of Android is the ability to run many tiny daemons, so you have realtime updates of anything you care to update. There's no switching-between, other than in the usual Linux sense of multitasking. If developers can't reproduce any feature Apple can (as one can relative to Android and Google), the OS is still crippled.
With rare exception, programs in the background are consuming little or no power in Android. This is Linux after all... a program that's not doing something or waiting to do something is sitting on a wait-task queue... it's not consuming any power until the thing it's waiting for (a timer, an I/O event, etc) happens. Sure, it's possible to write an evil application that sucks power in the background... I've seen one of these since I started using Android five months ago.
The small win with multitasking is the ability to very rapidly switch between applications. I do this all the time, and it's dramatically more efficient than on any single tasking OS, like PalmOS or iPhoneOS.
The big win is intentional background processes, eg, daemons in Linux-speak. So any application can stick around and do its job, monitoring other forms of communications, checking the weather, tracking or changing settings based on locale, or simply offering me the same ability in any old program (Pandora, Museek) that Apple reserves for just their apps on the iPhone.
HSPA+ has actually been rolled out already by AT&T.. that's the 7.2Mb/s you hear in ads all the time. The problem with HSPA+ is the same problem GSM has always had.
The original voice/2G protocols ran on 1.25MHz down, 1.25MHz up channels. The CDMA folks (Verizon and Sprint) run EvDO Rev A, which does 3.1Mb/s down, peak, on these same channels. This is why virtually every CDMA cell in the USA is 3G.
The original HSPA wants 5MHz up and 5MHz down, to deliver 3.6Mb/s downlinks. Unfortunately, this demanded all new spectrum and hardware. So this, among other issues, it why only about 20% (by area) of the AT&T cells do 3G.
HSPA+ works by pairing two separate cells on the same tower. You get 7.2Mb/s downloads, peak, but this requires 20MHz of bandwidth. So there are plenty of locales, in the USA, in which you Telco of choice simply doesn't own that spectrum. AT&T has announced they'll have 40-50 cities on HSPA+ this summer. They're waiting for 2011 for an LTE rollout, on their 12MHz chunk of the 700MHz spectrum.
Verizon is also going to LTE, and claims they'll have 30-40 cities covered when they go hot this summer. We'll see. They have a 20MHz chunk of the 700MHz spectrum in the USA.
As opposed tot the Appleists, who hold fast to the principle that "wireless network u/l speed shall not increase" (all iPhones can only do 384kb/s uploads... despite the HSPA+ rate of 2Mb/s, which is supported by most other current GSM smart phones).
Well, the HSPA+ modem is only a potential. HSPA+ is also supported on many smart phones, and even on the download side by the iPhone 3GS (upload is still the basic 384kb/s, not even HSPA-regular speeds).
And yeah, ideal HSPA+ download rates hit 7.2Mb/s. Sprint is claiming 6Mb/s for their WiMax "4G" link, while Comcast and Clear claim 8Mb/s and 10Mb/s or more.. funny thing, though.. it's exactly the same WiMax network.
As for HSPA+, AT&T claims they'll have rolled it out in 30-40 cities, as of this summer. If you're not in-town, or not in the right town, don't expect to get faster connections. But much of this is marketing hype anyway. If you listen to Sprint ads, you'll expect to find 4G is a real thing. And it is... for computer connections. But they have yet to ship a WiMax phone.
And I can sympathize about that "incredible thing" 1000 miles away. Or 3 miles away. Where I live, there's no wired broadband offered. So I'm paying $120 a month for satellite at 1.5Mb/s down, with heinous download limits per day. Three miles away, there's 12+Mb/s cable with no announced per-day limits.
This summer, Verizon 4G comes online, too. They're using LTE, the global standard, not WiMax, and on 700MHz (versus 2500MHz for WiMax), so they have a big advantage. They're going hot in 30-40 cities all at once. LTE trials have demonstrated 50Mb/s links, but once it gets real, there are per-client maximums imposed, regardless of the actual cell traffic. I'm in a local totally ready for this as a home connection, there's "Stimulus" money to hit up us rural folks, and yet, I still imagine Verizon hooking this up in places that already get Cable, FiOS, and HPSA+ just dandy.
A proper test would look at the beginner's experiences with different entry methods, and also experts -- folks using these things regularly for months or years. There's every chance of a "Coke vs. Pepsi" situation here, where some are simply easier to use out of the box, but others work better as the user gains proficiency. I'd add in other alternate virtual keyboards, too, like Swype.
And curiously, I ran into this with my old Treo 700p. The keyboard finally bit the dust. Had they included the normal PalmOS stylus area on-screen, this would have been an annoyance. As it was, it was pretty much useless at that point.
While I haven't run Emacs on my smart phone, native or via SSH, it's nice to know I could. With a decent screen resolution and keyboard, it's totally practical on many of today's smartphones. In fact, I'd get more text on-screen on my Droid than I did when I first used Emacs, way back when, on VT52 terminals.
I think Apple actually had a patent on form over function... going all the way back to the mouse cut down to a single button. But some people appreciate the form and don't understand the missing function anyway. Thus the success of these bad ideas, particularly with people otherwise confused by electronic devices.
The big problem with the virtual keyboard isn't so much the fact it's non-mechanical, but that it takes up a huge bit of real-estate on an already too-tiny screen, in the case of the iPhone and similar old-style smartphones. Once you get to the current 800x480-ish resolution of current-generation high-end smartphones, this is a but less true, but only a bit -- screens and fingers are still the same size, even if you have 2x-3x the resolution.
And as well, having a physical keyboard doesn't preclude the use of a virtual one. For simple things on my Droid, I use the virtual keyboard and, increasingly, voice. But for actual extended writing, the physical keyboard wins.
Of course, none of these things are immediately natural to your fingers if you're used to full sized computers. I can touch-type on my PC keyboard here... never had a lesson, but youi know, after a few decades at it, it's second-nature. But every tiny device, I'd had to train my fingers all over again before it became comfortable -- Palm stylus alphabet, Treo keyboard, iPhone virtual keyboard, Droid virtual and physical keyboard, they're all just different enough, we adapt to them. Most people don't notice it.. they just discover at some point they're very happy, or at least at terms, with the device they're using... and probably hate others. No one's really got the tiny keyboard good enough for most people to live it from the start.
Dirac is potentially wonderful. But it will need work. It's based on Wavelets, which have a ton of potential, but not much practical use. I'm familiar enough, though, I have been using Cineform on the PC for about 5 years. Cineform is proprietary, Wavelet based, and much more comparable to Dirac Pro (now enshrined as the SMPTE VC-2 standard) than Dirac (the whole intraframe compression issue).
In short, AVC, DiVX, Theora, MPEG-2, WMV, etc. are all DCT-based. That's both good and bad. The good is that there's sometimes hardware to accelerate that, there is a long tradition of understanding these things, some of it's actually mature enough to live in realtime hardware, etc. On the downside, there's been so much work there, there are patent minefields... one factor preventing Theora from matching VC-1 or AVC in efficiency. And DCT-based compression artifacts are inherently more obvious to the human eye than Wavelet artifacts... they're there, but to my eye anyway, they seem more "organic".
But Dirac will need work to speed it up and perfect it. The good thing is that it's starting out open source, so this work can technically happen in full view of the FOSS community.
The reason he cares about all those large fields is support on small devices, and support for good streaming. On a PC, from disc, "who cares" is the right answer. On a pocket media player, it's not. Or on a network, where small packets work much better. In MPEG-2 transport streams, the packet is about 208 bytes in size. TS works very well over any kind of streaming media, and it's the format of choice on Blu-Ray and most digital camcorders. If you hinky up a packet with all kinds of needless overhead, you need gigantic packets, which means less effective streaming.
For devices, he predicts a minimum of 128K just for packet management. Not a huge amount by PC or smartphone standards, but that's crazy RAM for many embedded CPUs, which could otherwise handle the playback just fine. Thus, the nearly complete lack of Ogg support in small devices.
You don't understand AVI.. it's a generic media holder, not a format. Sure, there are low quality AVI formats. On the other hand, I have a couple of 120-or-so-GB AVI files on one of my HDDs right now, with video about twice the resolution of Blu-Ray. AVI can contain just about anything.
Most older P&S cameras record Motion JPEG in either AVI or Quicktime (.mov) format. Some are lower than DV quality, but not all. The video recorded by my Panasonic DMC-TZ5 is 1280x720/30p in MJPEG (in a Quicktime wrapper), generally better than DV from most consumer camcorders.
Windows ships with a DV CODEC, so DV files generally work. It does not ship with an MJPEG CODEC, and in fact, there's no Windows standard for the small details in MJPEG. If you have a camera that does MJPEG video in AVI, it comes with a disc that includes an MJPEG CODEC for its particular flavor of MJPEG. It was kind of stupid for Microsoft to not standardize this, but they didn't. Apple did, which is why most of the newer cameras doing MJPEG are using Quicktime containers. Canon makes some sweet cameras, but they've been way behind on video-in-P&S issues. Thus, my Panasonic P&S, despite the fact I own several Canon film cameras, one DSLR, and a DV camcorder.
I should also point out that media containers were not originally designed for random things being distributed over the internet. Rather, they are for developers to author and users to play back.
As a professional, if I put stuff on a DVD or a Web site that the average computer user couldn't see, that disc or site would include whatever drivers or CODECs one needed in order to video my media. That's still pretty much the rule.
This is very useful for professional work. For example, I bought a license for the Cineform CODEC, which is an "intermediate" CODEC, designed for fast editing of computationally expensive formats like MPEG-2 and AVC. Not so expensive on their own, but try doing 10 or 20 layers of video in a single project, and you'll meet "slow" on any PC. The multimedia frameworks allow video and audio editors to use new CODECs without any changes to their own code.
At the fringes, sure, you have pirates and crazy people putting weird stuff inside AVIs, without telling you what it is. But this is not a general problem.
The issue is, there's a crazy level of information in every video file, which is not terribly useful to the average user... too much to include in the filename, and for no real value. There are free programs, like GSpot, that will analyze the contents of an AVI for you. This is one of those situations in which, if the information is useful to you, you probably already have this kind of tool, if not, you're just going to get confused by silly solutions such as 60-character filenames.
Sony Vegas don't have an MJPEG CODEC built-in.. but neither does Windows. MJPEG itself was never standardized as an AVI format, because Microsoft never supported it. There were several different, not quite compatible versions of MJPEG on AVI in the years before DV, and they all kind of went away after DV came out. DV is basically just a standardized MJPEG, after all.
Where MJPEG is standard, it's usually done in Quicktime, because Apple set the standard by brute force: here's the MJPEG specifics for Quicktime, use them or die. So pretty much every digital still camera that does MJPEG produces a.mov file, not a.avi. If they do the.avi, they include a disc with MJPEG CODEC for Windows.
Incidentally, out of the box, Vegas supports MJPEG on Quicktime quite readily. There's just no standard in Windows, so unless you installed the CODEC that came with your device, you probably don't have it.
Now, some will say that Matroska wasn't designed specifically for streaming, and that's true. There are issues, like the fact there's no limit on the size of clusters, that make streaming any arbitrary Matroska file a problem. But that's not really a good argument against it... it's easy enough to tweak a Matroska writer to create more a good stream, without changing the format.
Of course, one can also point out that Ogg was only designed for audio, it wasn't even a great audio format anyway, and that dropping video in there was a complete boondoggle.
Ogg is the container, not the CODEC. Ogg is terribly flawed, and yet, the Xiph folks keep using it. There are far superior containers, particularly Matroska, that are not patented, are fully open, available under LGPL or BDS licensed, and implemented on dramatically more devices than Ogg. Matroska compares very favorable to the capabilities of the MP4 container, it's a big advance over some of the older stuff, some of which (like the MPEG-2 transport stream) is still far superior to the Ogg container.
You can make weak arguments about not using some of these other containers, though most are so old, the chances of patents still being valid are small. Good arguments for not using AVI, Quicktime, or MP4 aside from patent issues would be things like "large organizations control additions to the specs". But Matroska is so much better than Ogg, it's growing, lots of people improving it and working on it, it's just as open source as Ogg, etc. It's bordering on criminal that Xiph hasn't simply tossed Ogg away in favor of Matroska.
This is one of those signs of "religion" over technology that makes so many of these open source efforts downright frustrating to folks like myself. I've worked in computer video pretty much since it existed (the Amiga 2000... my name's on the motherboard), I completely understand the issues. And yet, we get all these little folks here trying to build their own islands of control or whatever, rather than really doing what's best for the FOSS community at large. This is the kind of myopia that kills startup companies, and it's one big reason why so many of these efforts are doomed to go nowhere, from the get-go.
Conversely, you can recognize an effort that's working by the fact it's going somewhere. PNG was such a project -- it addressed a need better than it had been addressed. And so it's in every browser now. Matroska is another good example of this... there's growing support for it, on PCs, on devices. It's a good, free solution, and it's a living and open project. More open than Xiph, for that matter.
If you have a proprietary container for every possible format, that makes it necessary for every player to learn that format, or for a multitude of players to exist... it gets ugly, real fast.
In a modern operating system, you have OS-level support for various media formats, via a multimedia framework, like DirectShow or Video for Windows under Windows, Quicktime under MacOS, or gstreamer under Linux. So it makes a great deal of sense to build a single "encapsulation" format for any kind of media.
Once you have such a format, a player is simply a program that parses the format, calls up the OS's multimedia subsystem, and sends the video it encounters based on type... or fails, if that PC doesn't have a driver (eg, CODEC) for that particular type.
This allows new media types to be added to the system and work with every tool. For example, I use Sony Vegas for video editing and rendering. The BBC just released a new video format, called Dirac, which is fairly interesting. All they have to do is release a VIDEO CODEC... just the piece that knowns how to encode and decode their format, and some hooks to identify it within the multimedia framework. When I install this in Windows, I can now read and write Dirac video in Vegas, I can play back Dirac video in Windows Media Player, etc. If every video format needed its own tools, or separate support within each application, then I'd have to wait for the BBC to compete their specs, then send them to Sony, and then for Sony to decide that Dirac was important enough to support in Vegas.
It's kind of the same idea as device driver support. Back in the ugly dark ages of MS-DOS, there was really very little operating system in place: MS-DOS just did file handling. So a program that did graphics had to know about your graphics card (or just go slow and generic), it has to know about your mouse or other pointing device, etc. So I might have a DOS based CAD program, it knows my graphics and my mouse, everything's cool. Then I go and buy a nice new tablet, for more accurate editing... but the CAD program doesn't know that tablet, so I can't use it. This was solved by modern OSs (eg, not MS-DOS) generations ago, by adding various device drivers into the OS. So your modern CAD program asks the OS about input, and the OS gets that information from any user interface devices you might have. The manufacturer of that device adds the driver, no need to support it in the application.
Video CODECs are just another class of abstraction similar to device driver, it's just not always seen that way, because the path is software to software (eg, compressed video to uncompressed video, vice versa) rather than software to hardware (eg, mouse driver to mouse).
H.264 is supported, for example, in Android. And guess what... Fennec, by all accounts, will be using the H.264 CODEC that's part of the OS in their Android port.
You don't seem to understand coding very well. Mozilla supports Firefox on a number of platforms: Windows, Linux, Mac, maybe others. This is hardly a single binary, each version has code that adjusts to the OS being targeted, using the resources of that OS for I/O of most kinds: file I/O, audio output, etc. But for some reason (or perhaps, some religious argument), Mozilla is insisting that the video CODEC for HTML5 needs to be built-in to the browser, despite the fact that, just like file management, graphics display, etc. this really belongs in the OS. And every major OS -- yeah, even Linux -- supports a multimedia OS API with support for multiple CODECs.
The reason why this is a proper OS resource is certainly that, like graphics and audio, video is pervasive these days. But it's also a practical matter. My Android example illustrates this: video can tap into hardware acceleration when it's written for the specific platform, and it can't when it's totally generic. It would be impossible to play Ogg Theora, H.264, or probably even MPEG-1 on most small device hardware directly, but using the OS-level H.264 CODEC, you get many hours of full motion video.
But this isn't restricted to portable devices. I can play a full 1080/60p video (about twice the normal "full HD" requirements) using about 12% CPU on my desktop under Windows 7, using plain old ugly Windows Media Player. Running that same video in VLC, I get a very choppy playback, and 60%+ CPU used. This is a high-end PC (well, a high-end Core2 quad machine, not so high-end by 2010 standards) and sure, I could play a Blu-Ray without worries, even without the GPU-based acceleration. But smaller PCs cannot... they need the acceleration, or they fail at playback. And even when not failing, they consumer many times the battery power bypassing hardware or GPU acceleration.
I have little problem with Mozilla or anyone else fighting the good fight, when it's a real good fight, based on technical merits. But they're not doing that... they are fighting a political battle they can't win, and in doing so, they're taking the very, very wrong side of a meaningful technical argument. Simply put, the Browser has no more business implementing a video CODEC than they do a graphics driver, audio driver, file system, or any other OS resource.
Actually, the first two describe why people use PNG. The third explains why PNG exists -- it was a direct response to Unisys patent trolling software companies. If PNG was only as good as GIF, no one who wasn't writing their own image encoder would have cared about PNG.
That's an important thing for Ogg/Vorbis and Ogg/Theora fans to keep in mind. Making something that does the same job, only free-as-in-beer-and-speech doesn't matter to any significant percentage of the computer using population. They pay for computers, generally with OS included, they don't notice if $0.10 of that purchase price goes to some licensing group or not. They only care about what works, and some care about "how well".
So releasing things that don't work as well is not as good way to replace the status quo. Ogg Vorbis has a higher coding efficiency than MP3, but hey, AAC has a higher coding efficiency than Ogg Vorbis, there's no license for broadcast of any kind, and it was pushed by Apple, which is, like it or not, the 362.87kg Gorilla in computer audio.
Ogg Theora is worse than AVC, and even the rigged demos on the Xiph Foundation web site illustrate this, just not as profoundly as, well, anyone actually doing this comparison "in the wild"... like, rendering Theora vs. AVC from the same 1080/60p HD originals at the same bitrate... which is why I hold this opinion -- I've actually done the deed.
MP3 was first because it actually solved the problem.. it was designed for encoding transparency (eg, sounds just like the original) over ISDN connections. This also worked very well for internet distribution, but just as much, for the need to compress audio to actually fit any useful number of music tracks on a flash-based player of the 1990s.
And the format did win out precisely because it was the only plays-anywhere format. Before MP3 players had large capacity, I could get CD players that played MP3 files. So my DVD player, every PC based program, later my boombox, my PDA, my iPod, my Zune, my DROID, my second boombox (Sony), my GPS device. It is still the only format you can guarantee will play on any media player today.
At the same time, it was the format of legal, non-DRMed music. Very early on, before Apple was even in the picture, eMusic.com was selling MP3s. Today, Amazon's download service is doing DRM-free MP3, because it plays on any device.
It also worked because, while Fraunhofer IIS did want licensing fees for the encoders and decoders, they agreed to not enforce this for open source/freeware encoders and decoders. So while there are patents on MP3, you're not illegally distributing an MP3 decoder or encoder on Linux.
Slashdot Mirror
Given that internet use on the iPhone is a flat $30 per month, this doesn't make AT&T any money. But yeah, that'll happen... there are hundreds if not thousands of apps on Android that can live in the background and do something interesting via the net.
Multitasking is a natural concept... it's the single tasking in any OS that has to be learned. Apple's been very good at teaching this as an acceptable limitation, to the point where the iPhonies defend this as some kind of intelligent choice, despite the fact their batteries last no longer than those of my Droid. I'm sure if Apple does introduce some kind of application multitasking, they'll be back to explain to us all why multitasking is suddenly A Good Thing, even though it wasn't in the past.
Is the "shit at work" app in the Android Marketplace?
I think my Droid is as snappy as the best of the iPhone line, at considerably higher resolution. Your Nexus One goes a step beyond that. And yeah, there are Dalvik improvements on the way. Nothing like an OS tweak to affect every application... Palm did this, twice now, with their WebOS (most WebOS apps are writting in JavaScript!!). Apple's playing catchup, or at least they ought to be, on a number of things. Multitasking is just one... how about screen resolution? Their treatment of the iPad, with its "run iPhone apps in the 480x360 naive mode" hack, suggests that they have no intention of supporting anything other than 480x360 anytime soon. That's fairly tragic... every modern top-of-the-line smart phone now has 800x480 resolution, or perhaps a bit higher. Also, the rumor suggesting an "interface for switching between apps" does suggest some weirdness... how about background tasks? One of the main strengths of Android is the ability to run many tiny daemons, so you have realtime updates of anything you care to update. There's no switching-between, other than in the usual Linux sense of multitasking. If developers can't reproduce any feature Apple can (as one can relative to Android and Google), the OS is still crippled.
With rare exception, programs in the background are consuming little or no power in Android. This is Linux after all... a program that's not doing something or waiting to do something is sitting on a wait-task queue... it's not consuming any power until the thing it's waiting for (a timer, an I/O event, etc) happens. Sure, it's possible to write an evil application that sucks power in the background... I've seen one of these since I started using Android five months ago. The small win with multitasking is the ability to very rapidly switch between applications. I do this all the time, and it's dramatically more efficient than on any single tasking OS, like PalmOS or iPhoneOS. The big win is intentional background processes, eg, daemons in Linux-speak. So any application can stick around and do its job, monitoring other forms of communications, checking the weather, tracking or changing settings based on locale, or simply offering me the same ability in any old program (Pandora, Museek) that Apple reserves for just their apps on the iPhone.
HSPA+ has actually been rolled out already by AT&T.. that's the 7.2Mb/s you hear in ads all the time. The problem with HSPA+ is the same problem GSM has always had. The original voice/2G protocols ran on 1.25MHz down, 1.25MHz up channels. The CDMA folks (Verizon and Sprint) run EvDO Rev A, which does 3.1Mb/s down, peak, on these same channels. This is why virtually every CDMA cell in the USA is 3G. The original HSPA wants 5MHz up and 5MHz down, to deliver 3.6Mb/s downlinks. Unfortunately, this demanded all new spectrum and hardware. So this, among other issues, it why only about 20% (by area) of the AT&T cells do 3G. HSPA+ works by pairing two separate cells on the same tower. You get 7.2Mb/s downloads, peak, but this requires 20MHz of bandwidth. So there are plenty of locales, in the USA, in which you Telco of choice simply doesn't own that spectrum. AT&T has announced they'll have 40-50 cities on HSPA+ this summer. They're waiting for 2011 for an LTE rollout, on their 12MHz chunk of the 700MHz spectrum. Verizon is also going to LTE, and claims they'll have 30-40 cities covered when they go hot this summer. We'll see. They have a 20MHz chunk of the 700MHz spectrum in the USA.
As opposed tot the Appleists, who hold fast to the principle that "wireless network u/l speed shall not increase" (all iPhones can only do 384kb/s uploads... despite the HSPA+ rate of 2Mb/s, which is supported by most other current GSM smart phones).
Well, the HSPA+ modem is only a potential. HSPA+ is also supported on many smart phones, and even on the download side by the iPhone 3GS (upload is still the basic 384kb/s, not even HSPA-regular speeds). And yeah, ideal HSPA+ download rates hit 7.2Mb/s. Sprint is claiming 6Mb/s for their WiMax "4G" link, while Comcast and Clear claim 8Mb/s and 10Mb/s or more.. funny thing, though.. it's exactly the same WiMax network. As for HSPA+, AT&T claims they'll have rolled it out in 30-40 cities, as of this summer. If you're not in-town, or not in the right town, don't expect to get faster connections. But much of this is marketing hype anyway. If you listen to Sprint ads, you'll expect to find 4G is a real thing. And it is... for computer connections. But they have yet to ship a WiMax phone. And I can sympathize about that "incredible thing" 1000 miles away. Or 3 miles away. Where I live, there's no wired broadband offered. So I'm paying $120 a month for satellite at 1.5Mb/s down, with heinous download limits per day. Three miles away, there's 12+Mb/s cable with no announced per-day limits. This summer, Verizon 4G comes online, too. They're using LTE, the global standard, not WiMax, and on 700MHz (versus 2500MHz for WiMax), so they have a big advantage. They're going hot in 30-40 cities all at once. LTE trials have demonstrated 50Mb/s links, but once it gets real, there are per-client maximums imposed, regardless of the actual cell traffic. I'm in a local totally ready for this as a home connection, there's "Stimulus" money to hit up us rural folks, and yet, I still imagine Verizon hooking this up in places that already get Cable, FiOS, and HPSA+ just dandy.
A proper test would look at the beginner's experiences with different entry methods, and also experts -- folks using these things regularly for months or years. There's every chance of a "Coke vs. Pepsi" situation here, where some are simply easier to use out of the box, but others work better as the user gains proficiency. I'd add in other alternate virtual keyboards, too, like Swype.
And curiously, I ran into this with my old Treo 700p. The keyboard finally bit the dust. Had they included the normal PalmOS stylus area on-screen, this would have been an annoyance. As it was, it was pretty much useless at that point.
While I haven't run Emacs on my smart phone, native or via SSH, it's nice to know I could. With a decent screen resolution and keyboard, it's totally practical on many of today's smartphones. In fact, I'd get more text on-screen on my Droid than I did when I first used Emacs, way back when, on VT52 terminals.
I think Apple actually had a patent on form over function... going all the way back to the mouse cut down to a single button. But some people appreciate the form and don't understand the missing function anyway. Thus the success of these bad ideas, particularly with people otherwise confused by electronic devices.
The big problem with the virtual keyboard isn't so much the fact it's non-mechanical, but that it takes up a huge bit of real-estate on an already too-tiny screen, in the case of the iPhone and similar old-style smartphones. Once you get to the current 800x480-ish resolution of current-generation high-end smartphones, this is a but less true, but only a bit -- screens and fingers are still the same size, even if you have 2x-3x the resolution. And as well, having a physical keyboard doesn't preclude the use of a virtual one. For simple things on my Droid, I use the virtual keyboard and, increasingly, voice. But for actual extended writing, the physical keyboard wins. Of course, none of these things are immediately natural to your fingers if you're used to full sized computers. I can touch-type on my PC keyboard here... never had a lesson, but youi know, after a few decades at it, it's second-nature. But every tiny device, I'd had to train my fingers all over again before it became comfortable -- Palm stylus alphabet, Treo keyboard, iPhone virtual keyboard, Droid virtual and physical keyboard, they're all just different enough, we adapt to them. Most people don't notice it.. they just discover at some point they're very happy, or at least at terms, with the device they're using... and probably hate others. No one's really got the tiny keyboard good enough for most people to live it from the start.
Dirac is potentially wonderful. But it will need work. It's based on Wavelets, which have a ton of potential, but not much practical use. I'm familiar enough, though, I have been using Cineform on the PC for about 5 years. Cineform is proprietary, Wavelet based, and much more comparable to Dirac Pro (now enshrined as the SMPTE VC-2 standard) than Dirac (the whole intraframe compression issue).
In short, AVC, DiVX, Theora, MPEG-2, WMV, etc. are all DCT-based. That's both good and bad. The good is that there's sometimes hardware to accelerate that, there is a long tradition of understanding these things, some of it's actually mature enough to live in realtime hardware, etc. On the downside, there's been so much work there, there are patent minefields... one factor preventing Theora from matching VC-1 or AVC in efficiency. And DCT-based compression artifacts are inherently more obvious to the human eye than Wavelet artifacts... they're there, but to my eye anyway, they seem more "organic".
But Dirac will need work to speed it up and perfect it. The good thing is that it's starting out open source, so this work can technically happen in full view of the FOSS community.
The reason he cares about all those large fields is support on small devices, and support for good streaming. On a PC, from disc, "who cares" is the right answer. On a pocket media player, it's not. Or on a network, where small packets work much better. In MPEG-2 transport streams, the packet is about 208 bytes in size. TS works very well over any kind of streaming media, and it's the format of choice on Blu-Ray and most digital camcorders. If you hinky up a packet with all kinds of needless overhead, you need gigantic packets, which means less effective streaming.
For devices, he predicts a minimum of 128K just for packet management. Not a huge amount by PC or smartphone standards, but that's crazy RAM for many embedded CPUs, which could otherwise handle the playback just fine. Thus, the nearly complete lack of Ogg support in small devices.
You don't understand AVI.. it's a generic media holder, not a format. Sure, there are low quality AVI formats. On the other hand, I have a couple of 120-or-so-GB AVI files on one of my HDDs right now, with video about twice the resolution of Blu-Ray. AVI can contain just about anything.
Most older P&S cameras record Motion JPEG in either AVI or Quicktime (.mov) format. Some are lower than DV quality, but not all. The video recorded by my Panasonic DMC-TZ5 is 1280x720/30p in MJPEG (in a Quicktime wrapper), generally better than DV from most consumer camcorders.
Windows ships with a DV CODEC, so DV files generally work. It does not ship with an MJPEG CODEC, and in fact, there's no Windows standard for the small details in MJPEG. If you have a camera that does MJPEG video in AVI, it comes with a disc that includes an MJPEG CODEC for its particular flavor of MJPEG. It was kind of stupid for Microsoft to not standardize this, but they didn't. Apple did, which is why most of the newer cameras doing MJPEG are using Quicktime containers. Canon makes some sweet cameras, but they've been way behind on video-in-P&S issues. Thus, my Panasonic P&S, despite the fact I own several Canon film cameras, one DSLR, and a DV camcorder.
I should also point out that media containers were not originally designed for random things being distributed over the internet. Rather, they are for developers to author and users to play back.
As a professional, if I put stuff on a DVD or a Web site that the average computer user couldn't see, that disc or site would include whatever drivers or CODECs one needed in order to video my media. That's still pretty much the rule.
This is very useful for professional work. For example, I bought a license for the Cineform CODEC, which is an "intermediate" CODEC, designed for fast editing of computationally expensive formats like MPEG-2 and AVC. Not so expensive on their own, but try doing 10 or 20 layers of video in a single project, and you'll meet "slow" on any PC. The multimedia frameworks allow video and audio editors to use new CODECs without any changes to their own code.
At the fringes, sure, you have pirates and crazy people putting weird stuff inside AVIs, without telling you what it is. But this is not a general problem.
The issue is, there's a crazy level of information in every video file, which is not terribly useful to the average user... too much to include in the filename, and for no real value. There are free programs, like GSpot, that will analyze the contents of an AVI for you. This is one of those situations in which, if the information is useful to you, you probably already have this kind of tool, if not, you're just going to get confused by silly solutions such as 60-character filenames.
Sony Vegas don't have an MJPEG CODEC built-in.. but neither does Windows. MJPEG itself was never standardized as an AVI format, because Microsoft never supported it. There were several different, not quite compatible versions of MJPEG on AVI in the years before DV, and they all kind of went away after DV came out. DV is basically just a standardized MJPEG, after all.
Where MJPEG is standard, it's usually done in Quicktime, because Apple set the standard by brute force: here's the MJPEG specifics for Quicktime, use them or die. So pretty much every digital still camera that does MJPEG produces a .mov file, not a .avi. If they do the .avi, they include a disc with MJPEG CODEC for Windows.
Incidentally, out of the box, Vegas supports MJPEG on Quicktime quite readily. There's just no standard in Windows, so unless you installed the CODEC that came with your device, you probably don't have it.
Yes, Matroska is dramatically better than Ogg.
Now, some will say that Matroska wasn't designed specifically for streaming, and that's true. There are issues, like the fact there's no limit on the size of clusters, that make streaming any arbitrary Matroska file a problem. But that's not really a good argument against it... it's easy enough to tweak a Matroska writer to create more a good stream, without changing the format.
Of course, one can also point out that Ogg was only designed for audio, it wasn't even a great audio format anyway, and that dropping video in there was a complete boondoggle.
Ogg is the container, not the CODEC. Ogg is terribly flawed, and yet, the Xiph folks keep using it. There are far superior containers, particularly Matroska, that are not patented, are fully open, available under LGPL or BDS licensed, and implemented on dramatically more devices than Ogg. Matroska compares very favorable to the capabilities of the MP4 container, it's a big advance over some of the older stuff, some of which (like the MPEG-2 transport stream) is still far superior to the Ogg container.
You can make weak arguments about not using some of these other containers, though most are so old, the chances of patents still being valid are small. Good arguments for not using AVI, Quicktime, or MP4 aside from patent issues would be things like "large organizations control additions to the specs". But Matroska is so much better than Ogg, it's growing, lots of people improving it and working on it, it's just as open source as Ogg, etc. It's bordering on criminal that Xiph hasn't simply tossed Ogg away in favor of Matroska.
This is one of those signs of "religion" over technology that makes so many of these open source efforts downright frustrating to folks like myself. I've worked in computer video pretty much since it existed (the Amiga 2000... my name's on the motherboard), I completely understand the issues. And yet, we get all these little folks here trying to build their own islands of control or whatever, rather than really doing what's best for the FOSS community at large. This is the kind of myopia that kills startup companies, and it's one big reason why so many of these efforts are doomed to go nowhere, from the get-go.
Conversely, you can recognize an effort that's working by the fact it's going somewhere. PNG was such a project -- it addressed a need better than it had been addressed. And so it's in every browser now. Matroska is another good example of this... there's growing support for it, on PCs, on devices. It's a good, free solution, and it's a living and open project. More open than Xiph, for that matter.
If you have a proprietary container for every possible format, that makes it necessary for every player to learn that format, or for a multitude of players to exist... it gets ugly, real fast.
In a modern operating system, you have OS-level support for various media formats, via a multimedia framework, like DirectShow or Video for Windows under Windows, Quicktime under MacOS, or gstreamer under Linux. So it makes a great deal of sense to build a single "encapsulation" format for any kind of media.
Once you have such a format, a player is simply a program that parses the format, calls up the OS's multimedia subsystem, and sends the video it encounters based on type... or fails, if that PC doesn't have a driver (eg, CODEC) for that particular type.
This allows new media types to be added to the system and work with every tool. For example, I use Sony Vegas for video editing and rendering. The BBC just released a new video format, called Dirac, which is fairly interesting. All they have to do is release a VIDEO CODEC... just the piece that knowns how to encode and decode their format, and some hooks to identify it within the multimedia framework. When I install this in Windows, I can now read and write Dirac video in Vegas, I can play back Dirac video in Windows Media Player, etc. If every video format needed its own tools, or separate support within each application, then I'd have to wait for the BBC to compete their specs, then send them to Sony, and then for Sony to decide that Dirac was important enough to support in Vegas.
It's kind of the same idea as device driver support. Back in the ugly dark ages of MS-DOS, there was really very little operating system in place: MS-DOS just did file handling. So a program that did graphics had to know about your graphics card (or just go slow and generic), it has to know about your mouse or other pointing device, etc. So I might have a DOS based CAD program, it knows my graphics and my mouse, everything's cool. Then I go and buy a nice new tablet, for more accurate editing... but the CAD program doesn't know that tablet, so I can't use it. This was solved by modern OSs (eg, not MS-DOS) generations ago, by adding various device drivers into the OS. So your modern CAD program asks the OS about input, and the OS gets that information from any user interface devices you might have. The manufacturer of that device adds the driver, no need to support it in the application.
Video CODECs are just another class of abstraction similar to device driver, it's just not always seen that way, because the path is software to software (eg, compressed video to uncompressed video, vice versa) rather than software to hardware (eg, mouse driver to mouse).
H.264 is supported, for example, in Android. And guess what... Fennec, by all accounts, will be using the H.264 CODEC that's part of the OS in their Android port.
You don't seem to understand coding very well. Mozilla supports Firefox on a number of platforms: Windows, Linux, Mac, maybe others. This is hardly a single binary, each version has code that adjusts to the OS being targeted, using the resources of that OS for I/O of most kinds: file I/O, audio output, etc. But for some reason (or perhaps, some religious argument), Mozilla is insisting that the video CODEC for HTML5 needs to be built-in to the browser, despite the fact that, just like file management, graphics display, etc. this really belongs in the OS. And every major OS -- yeah, even Linux -- supports a multimedia OS API with support for multiple CODECs.
The reason why this is a proper OS resource is certainly that, like graphics and audio, video is pervasive these days. But it's also a practical matter. My Android example illustrates this: video can tap into hardware acceleration when it's written for the specific platform, and it can't when it's totally generic. It would be impossible to play Ogg Theora, H.264, or probably even MPEG-1 on most small device hardware directly, but using the OS-level H.264 CODEC, you get many hours of full motion video.
But this isn't restricted to portable devices. I can play a full 1080/60p video (about twice the normal "full HD" requirements) using about 12% CPU on my desktop under Windows 7, using plain old ugly Windows Media Player. Running that same video in VLC, I get a very choppy playback, and 60%+ CPU used. This is a high-end PC (well, a high-end Core2 quad machine, not so high-end by 2010 standards) and sure, I could play a Blu-Ray without worries, even without the GPU-based acceleration. But smaller PCs cannot... they need the acceleration, or they fail at playback. And even when not failing, they consumer many times the battery power bypassing hardware or GPU acceleration.
I have little problem with Mozilla or anyone else fighting the good fight, when it's a real good fight, based on technical merits. But they're not doing that... they are fighting a political battle they can't win, and in doing so, they're taking the very, very wrong side of a meaningful technical argument. Simply put, the Browser has no more business implementing a video CODEC than they do a graphics driver, audio driver, file system, or any other OS resource.
Actually, the first two describe why people use PNG. The third explains why PNG exists -- it was a direct response to Unisys patent trolling software companies. If PNG was only as good as GIF, no one who wasn't writing their own image encoder would have cared about PNG.
That's an important thing for Ogg/Vorbis and Ogg/Theora fans to keep in mind. Making something that does the same job, only free-as-in-beer-and-speech doesn't matter to any significant percentage of the computer using population. They pay for computers, generally with OS included, they don't notice if $0.10 of that purchase price goes to some licensing group or not. They only care about what works, and some care about "how well".
So releasing things that don't work as well is not as good way to replace the status quo. Ogg Vorbis has a higher coding efficiency than MP3, but hey, AAC has a higher coding efficiency than Ogg Vorbis, there's no license for broadcast of any kind, and it was pushed by Apple, which is, like it or not, the 362.87kg Gorilla in computer audio.
Ogg Theora is worse than AVC, and even the rigged demos on the Xiph Foundation web site illustrate this, just not as profoundly as, well, anyone actually doing this comparison "in the wild"... like, rendering Theora vs. AVC from the same 1080/60p HD originals at the same bitrate... which is why I hold this opinion -- I've actually done the deed.
Not quite.
MP3 was first because it actually solved the problem.. it was designed for encoding transparency (eg, sounds just like the original) over ISDN connections. This also worked very well for internet distribution, but just as much, for the need to compress audio to actually fit any useful number of music tracks on a flash-based player of the 1990s.
And the format did win out precisely because it was the only plays-anywhere format. Before MP3 players had large capacity, I could get CD players that played MP3 files. So my DVD player, every PC based program, later my boombox, my PDA, my iPod, my Zune, my DROID, my second boombox (Sony), my GPS device. It is still the only format you can guarantee will play on any media player today.
At the same time, it was the format of legal, non-DRMed music. Very early on, before Apple was even in the picture, eMusic.com was selling MP3s. Today, Amazon's download service is doing DRM-free MP3, because it plays on any device.
It also worked because, while Fraunhofer IIS did want licensing fees for the encoders and decoders, they agreed to not enforce this for open source/freeware encoders and decoders. So while there are patents on MP3, you're not illegally distributing an MP3 decoder or encoder on Linux.