Yeah... open source alone is not always an important figure of merit if you have real work to do.
But you need to flip it around. GNU/Linux is very, very useful, and this largely because all these developers already understood how useful UNIX was, as used that as the basis for GNU/Linux. It is the case that "already proven good" + "open source" >> "already proven good", at least for most values of "always".
There are a few very useful media container formats around: MPEG-2 TS (ITU-T Rec. H.222.0), QuickTime, MPEG-4 (SO/IEC 14496-14), Matroska, going all the way back to IFF on the Amiga (and of course, that one 100% free and clear to clone and extend at will.. 1985 wasn't exactly a banner year for computer video). As much as it's often said that those who don't understand UNIX are doomed to recreate it, poorly, there's absolutely no question this is true of something as relatively simple to get right and painful when wrong as a media container format. The very simple ability to add a new format, and for a reader/player/editor to ignore formats it doesn't know, is one fundamental requirement. Other useful requirements include the ability to stream well... both reasons MPEG-2 TS still dominates in transmitted media (television, satellite, DVD & Blu-Ray, etc).
That's not to suggest MPEG-2 TS is ideal (it was written for hardware decoders, but, then again, tools to deal with TS streams abound already in all modern OSs). Or Amiga IFF, or Quicktime/MP4. Patent-wise, the MP4 file format was derived directly from the Quicktime (.mov) file format, which dates back at least to the early 1990s. So even if Apple has patents, they can't be all that long lived. But Ogg does things in stupid ways that were long ago handled much better by these other formats. It's pretty clear that the Ogg format creators were solving the short-term goal of encapsulating Vorbis, and subsequent projects should have dumped it in favor of something else.
And in particular, why not support Matroska? This is a very well done media container format. It's an open standard, and the libraries are licensed on LGPL, with parsers and player libraries under the BSD license. There's growing support for Matroska in software media players, hardware devices (TVs, Blu-Ray players), etc. And no known patent entanglements, just like Ogg. NIH maybe? The Theora and Vorbis people don't like Russians?
Brown isn't fugly, it's a great color. The color of my hair, my guitar, and my Zune. The color of my coffee, the color of chocolate. The color of Halle Berry.
OSX in metallic... yeah, I didn't get enough of that in Linux in the early 1990s. Looks horribly dated. Windows 7 is something of an improvement over XP, mainly because they removed the annoying and distracting candy-coloring or everything, and used "translucent" to make the theme virtually neutral.. change your background, and you're good to go. Same reason most professional media content software uses neutral greys for much of the interface: let's not distract one away from the actual use of the system.
Brown worked in this pretty well, too. Purple, not so much.
..ah say, what profession, deems brown unprofessional and orange and aubergine professional? Are they serious?
Yes, clearly, the color scheme has been holding Ubuntu back... riiighhhtt. And if they're changing it, couldn't they choose a background that says something to me other than "dude, your monitor needs degaussing"... yeah, I'm on LCDs too, but that background has to go.
Pond liners are generally made of plastics that can easily 50 years in sun (albeit some of it attenuated by water, in varying degrees). It's a truth that most plastics break down over time in the sun, it's generally a sad thing that many take a good thousand years to do so, even when not engineered for long life in the sun.
Doubled-plus. Sure, there are 40% efficient solar panels, if you have a satellite or space probe budget. Others are more like 20%, and when you're talking about super cheap panels, 10% is kind of a magic number. On the ground, 20%-ish for conventional or 10%-ish for super-cheap is already on-par, long-term, with other energy sources. If these really achieve 86% efficiency and don't cost a bloody fortune, this is revolutionary. Holy balls indeed!
Hmm... yeah. He's not sensitive to the guy's cellphone before the call, even though that phone is transmitting beacons all the time, to remain in contact with the local tower. Sounds like a nut. I did read the article, but it was just about this guy, and didn't offer any real critique. They should have sent a reporter out there with a 2-something GHz "white noise" generator in hit pocket. Or better still, do a real double-blind test. If the guy's actually sensitive to higher UHF spectrum RFI, that would be pretty interesting. Far as anyone knows, this stuff can't be detected by biological critters in any way. Some critters do, however, detect magnetic fields.
Well, part of the problem is that these systems all started out, ten or so years ago, as "clones" of TiVo... or at least efforts to replicate what TiVo did well. Microsoft did likewise with their Media Center shell. And the big problem they all had, and some still have, is stability. You still you're you're using a PC, not an appliance. Most of us here don't find that to be a huge problem, but the average TV viewer doesn't want or need PC-like issues to get the way of their TV viewing.
No crashing, no missing shows (in ten years, the only time my TiVo misses a recording, other than during power outs, was when the IR blaster wasn't seen by the STB correctly -- a problem with the STB, really.. other STBs allow serial connections that never fail this way). If I yank the plug on a DVR, I can't have a 5 minute startup while the device CHKDSKs or fscks... it has to be ready, immediately. It has to run quiet and cool... no heating up in an enclosed cabinet (the PS3 fails this, but it doesn't have to remain on).
And of course, regular consumer guy has to have a way to buy it, as an appliance. Sure, I could set these up for people easily enough, but at some point, you really find you're already doing enough free IT work for friends and family on their computer systems... you don't want to ask for more of that if you can help it. I have yet to see any of these systems work as reliable as I'd need for a consumer product.
Increasingly, there's no functional difference between "televison" and "computer video display". I'm on my fourth television with VGA inputs. Just about any TV these days supports HDMI input... HDMI is a superset of DVI-D... so pretty much any digital TV can display HD computer video. Going the other way, many of the new cheap LCD monitors are made using panels originally designed for TVs (hint: the computer standard is 16:10, the video standard is 16:9... all those cheap 1920x1080 monitors are really using TV panels).
And really, what's the difference once you're digital... is there anything particularly different when the TiVo makes an HD image using a DVB-HD SOC, rather than your TV doing it with an ATSC SOC, your PS3 making it with its dedicated graphics chip, or your PC doing it with nVidia or AMD/ATi graphics? A video signal is a video signal, there days.
I have monitors here, from the new Westinghouse company. They're on 16:10, 1920x1200 MVA panels, so very computer-industry. No turner, either. But they support HDMI rather than DVI, including audio over HDMI, so you can use these for stand-alone video playback. Plus, they support VGA, YPrPb, S/V and CVBS analog inputs... so you can connect up practically any video device made in the last 50 years and get an upconverted picture.
One of my kids has a 28" LCD TV, but it does a full 1080p image, and looks great as a computer monitor. And in fact, the same company (Hann) makes the identical screen in the same plastic, without the tuner and with a DVI input, and sells it as a monitor.
The "monitor vs. TV" thing is really not much of a question anymore. You probably find that for TV use, there's at least a mode (on an LCD display) for dynamic contrast (native LCD contrast is usually 1000:1 or so, CRT-based TVs offer at least 10,000:1)... for computer use, there's a mode that guarantees 1:1 pixel mapping, not always the default on a TV, even a digital one.
It actually kind of is. The recording is trivial, since, when you're "recording" HD, you're just recording the MPEG-2 transport stream to HDD, rather than actually creating an MPEG-2 data stream. This is going to a maximum of 19.4Mb/s per channel recorded, which is no big deal given the 30-50MB/s writes a modern HDD can support.. you just need enough buffering to not get killed by seek times. For playback, they're all using MPEG-2 or perhaps MPEG-4 decoder chips, designed for appliances like set-top boxes or Blu-Ray players. That's actually the big computational element, but all in hardware... so playback is only fetching the fairly low bitrate transport streams, anyway.
The only problem a PC had with this is the playback... if you're decoding full 1080/60i or 720/60p HD in MPEG-4, you basically need two CPU cores per stream. Or very good GPU acceleration (I can do a 1080/60p stream on my Q9550 machine with about 12% using a nVidia 8800GT with DVXA 2.0 acceleration.. that goes to about 60% playing back in VLC). But the big win using hardware decode is power. Even with simpler CPUs, like in the PS3, you run up to 250W as a player, versus maybe 25W for a dedicated Blu-Ray device. Obviously, home-made DVR-PCs cover this range, and beyond, depending on how much work you give them.
TiVo originally offered the lifetime subscription... I have this on my first TiVo box. It's a good investment, given this TiVo is around 10 years old, but also because it lowered the monthly fee on the second box. Since the very early days, TiVo has sometimes offered the lifetime subscription, sometimes not, sometimes allowed transfers (eg, when pushing Series 3 hardware to Series 1 owners like me... unfortunately, doesn't work with satellite HD), etc. So depending on when you bought a TiVo, lifetime subs were not always an option.
The PS3 isn't quite a TiVo replacement. Sure, you can download videos.. that was a retrofit into the TiVo, but it's also a pretty standard feature of most 2010-vintage dedicated Blu-Ray players. I suggest that "plays Netflix" is even more of a check-mark feature in modern set-top devices than "DVR" is today.
The PS3 is also a generally better video jukebox than a TiVo... it plays more video formats (ok, I haven't spent much time with a "Series 3"), it streams video over wireless or wired Ethernet without hacks or slowdowns, and in particular, it supports external storage, very easy internal drive upgrades, and built-in backup support to external media. In fact, the instructions for HDD upgrade were in the manual, at least when I got my PS3.
But the PS3 is not a functional time-shifting device... no way to record video.
ATSC broadcast is 19.4Mb/s in the USA, which is the limit on 1080/60i or 720/60p that's broadcast. Usually, the OTA broadcaster will have an SD aux channel or two.. these are typically 2-3Mb/s. So you might expect 15-17Mb/s in practice, OTA. Going to H.264 should give you the same quality at 6-9Mb/s, depending on the material and the encoder. That's kind of the practical upper bound for broadcast.. Blu-Ray videos are generally much higher bitrate. On the low end, YouTube does 720/24-30p video at 2Mb/s, and Netflix varies from 2.8-3.6Mb/s on their HD (all 720p as well) videos, but they're using the somewhat less efficient SMPTE VC-1 (Windows Media 9) CODEC.
So realistically, streaming two HD channels at broadcast quality over your home broadband? Not happening in most homes, even if the net itself were not the bottleneck. This is why TV providers are not using an IPTV model for, well, any real video.
H.264 offers 2x-3x the coding efficiency of MPEG-2, when done very, very well. If you're taking a source well rendered to MPEG-2 at 6Mb/s and MPEG-2 (assume SMPTE AC-3 audio for both) down to 1.5GB/hr, you are losing quality.
For broadcast quality (1080/60i or 720/60p), you're still talking 10-12GB/hour for MPEG-2, and no less than 3-4GB/hour for very well rendered H.264. Some of the render-on-the-fly stuff for H.264 is still lacking (eg, the encoding has been rapidly evolving, MPEG-2 pretty much a done deal), so for unit quality, you're more likely to see 5-10GB/hr for AVC at the same resolutions. Of course, cable and satellite companies have no problem compromising quality, and on the internet, they first thing anyone does is cut the source down to 720/24-30p.
As for live streaming, no, latency isn't that important... it's not as if there's enough storage in any video pipeline for crazy latency issues anyway. Now, you're talking about interactive video, that's where the latency becomes a real issue. And there are even ways to trick-play around that, if there's need.
TiVo, and nearly at the same time, Replay, popularized devices designed entirely for time-shifting... call 'em PVR or DVR, same thing. Basically, while a VCR could do this, it was ill suited to it -- serial storage, a maximum of 8hr of recording time if you'll accept the heinous qualify of EP recording on extra long tapes.
This worked fairly well over-the-air or to an analog satellite or cable box.. I still have two TiVos in my house. As a technology, they did some smart things. The user interface was so bloody easy, folks with flashing "12:00" on their VCR might actually manage to use the device (particularly if they got your average 14 year old to help wire it up). They didn't just merge EPG and VCR, they figured out why that's a synergy -- you could "subscribe" to a season of a show, non-specific about the time. And the TiVo would track your viewing habits and auto-record extra stuff.. still one of the best features.
There were two big problem, though. First was the ascendancy of pay TV, Digital, and DRM on video. Anyone can make an ATSC receiver for OTA digital TV, but (in the USA, not everywhere) cable and satellite were both proprietary. So no easy path to an HD TiVo that works as well as SD TiVo did on SD video. TiVo didn't want to add the expense of encoding analog or unprotected HDMI to MPEG or whatever HDD format they wanted, and yet, without access to your cable or satellite bitstream, they couldn't simply save that existing bitstream. There was lots of politics going around to standardized on DRM and cable hardware independently of cable provider, but the cable companies really didn't want this. They ultimately were forced (1996 Telecom Law) to accept what became the somewhat sabotaged CableCARD standard (used on the HD TiVo), but begrudgingly at best (a good lesson in the doublethink of forcing an industry to create the technology they don't want in the first place). And even once it finally materialize, many services made it hard to get one, they screwed around with how it worked, and generally made you feel second class, versus using a cable box directly. And there's no such option for satellite.
But the big thing... the basic PVR idea is not difficult to build into a digital device, particularly if you're already a digital receiver with a bitstream that can be tapped. I was designing an "advanced" set-top box with a German startup company I co-founded (Metabox AG) back in 1998-2000, and we did this. You have a DVB tuner and decoder, at some point there's an MPEG-2 transport stream, which you split to get the channel you're after (there can be up to 32 channels in a single transport stream). So, rather than sending that to the MPEG-2 decoder, you save it on disc. Add some smarts around that, and you get a PVR for the price of a hard disc... much easier than in the analog days, having to do the encoding.
That's really the problem TiVo got hit with... this is just a new feature to add to STBs for cable and satellite. I haven't seen any quite as user-friendly as TiVo, but on the other hand, I'm a computer wizard.. I really don't need all that much hand-holding. My Dish ViP 622 is slightly harder to use than a TiVo, but it seems a little less arduous as well. Now, Dish didn't get this right from the get-go... they inflicted some of history's worst PVRs on their customers before getting it decent. But the ViP 622 is just dandy... 2 sat and 1 OTA channels recording in HD while one HD and one SD can play back. That doesn't suck. Or the fact it can tap HDDs up to 1TB for external storage, offloading of video you need to keep around for awhile.
This was inevitable, once the TV "player" became digital. TiVo got popular, satellite and cable companies used "it's like TiVo" to offer you a "free" device (with 2-year contract) rather than your having to buy one. And they often make it free, too... after all, you're already paying for the EPG. Satellite really had to make these very good, to have any hope of competing with cable on things like on-demand video. Cable in turn added it to com
Ok, so I live on a tree farm in South Jersey. For some reason we're getting mad snows this season, rather than the usual 1"-then-melt situation. So, I'm at Sears early last month, loading a "Craftsman Professional" snowblower in to the back of my pickup. I jump down from the tail gate... DROID keeps going. Ouch!
Apparently, it landed and bounced... I had crawl under the truck to find it. But not only did it survive... not a scratch. I am not kind to mobile hardware in general, and I did have insurance on it, but damn... DROID DOESn't BREAK!
Of course, I should add, with 2.6x more pixels to paint, a DROID or Nexus One, even with a faster GPU, might well lose a frame-per-second race against an iPhone 3GS.
Well, the iPhone 3GS sure outperforms the older PowerVR MBX-Lite use in all previous iPhones. The MBX-Lite used in the older iPhones does about 1Mpolys/second at the iPhone's 50-60MHz GPU clock speed.
There is a THEORY that the GPU is an underclocked PowerVR SGX 535 (Intel calls this the GMA500), largely based on some #defines in the Apple SDK. And also because they include the VXD370 media accelerator, which has usually been coupled with higher-end SGXs. Of course, TI didn't need this, they have had their own media acceleration technology going back to before the DaVinci SOCs (what you find in most higher-end PMPs going back some years). This is a chip custom-made for Apple by Samsung, so in truth, unless Apple's talking, we may not know. The Anandtech article also postulates the SGX 520, but again, any number of core + clock speed combinations lead to the same answer. http://www.anandtech.com/gadgets/showdoc.aspx?i=3579
But a full SGX 535 runs at 200MHz and does 28 MPolys/s. Pretty good chance that's not what the iPhone 3GS is running -- there are no benchmarks showing even half of that performance. Most benchmarks show the 3GS running 3x to 7x faster at 3D, an assuming the faster CPU isn't part of that, you could get with an SGX 535 at 50MHz, an SGX 530 at 100MHz, or an SGX 520 at 200MHz. The real answer might be known to developers: the SGX 520 has a single Universal Scalable Shader Engine (USSE) pipeline, the others add multiple pipelines for additional performance. Not that you'd necessarily have this exposed in OpenGL.
It is not debatable about the DROID/Milestone.. it contains OMAP 3430, which contains the PowerVR SGX 530 GPU core. TI quotes a peak of 10Mpolys/sec. which this chip at normal clock speeds; it's programmable, typically run in the 100-160MHz range (14Mpolys/sec is the peak you can expect with 200MHz clock). Of course, there are all sorts of folks boosting their DROID to much higher clock speeds, but this what you'd expect in stock performance. And it's quite possible there are still optimization issues in Android that no longer apply to the slightly more mature iPhoneOS.
App upgrades are actually handled just dandy.. at least in the Android Market. Anything you downloaded via Android Market will show up, once updated in the market, as a notification of a new app. In fact, it's better than Windows and as good as Linux... as long as you got all your Linux apps via update-manager or something similar. It works, and it's properly centralized. As opposed to Windows, where, if you're not careful, you'll wind up with a few dozen "check for update" daemons. Yuk.
Far the OS... yeah, they screwed the pooch on this. The problem is not understanding the process of OS release, but not understanding the fact that phone and CE companies don't have much of a clue about dealing with application processing platforms. If you got a DVD player back in the 1990s, there's a good chance it didn't support DVD-R, and worse yet, DVD+R. But this was not usually a shortcoming of the hardware design, but rather, bugs in the DVD reference code. I have a Pioneer DVD player around here somehere, not based on the Toshiba/DVD Forum reference code, which worked with all of those new formats. The CE companies simply looked upon this as a way to sell new DVD players.
With all that's evil about Apple these days, their distant personal computer heritage has them smart about OS upgrades. So virtually any iPhone can run the latest iPhoneOS. That's easier when you're centrally managed, but not that hard otherwise.
The key to this kind of upgrade is a truly modular OS. That's kind of the anthesis of Linux thinking... it wasn't all that long ago when "rebuild the kernel to add that new device" was kind of the answer to that thing you just added to your PC. Android really should have had a number of independent modules.
Module #1 is the HAL (hardware abstraction layer). Motorola and HTC author HALs, and build them into the smartphone,This is a standard, low-level interface to each chunk of hardware, done in a standard way. Nothing as complex as a device driver, this is basically a plug: storage devices all look the same, cameras, screens, etc.
Module #2 is the OS. This comes from Google. Using the HAL, every device can drop in that OS... it essentially plugs into the HAL on every phone. This would largely eliminate the need to make OS upgrades the hardware company's problem. New hardware supported in the OS would simply not mate with HAL objects.. no problems. Google pushed out 2.1 (or any other developer) and you can drop that new binary into any phone, with memory limits.
Module #3 is all apps. So the "home" screen, whether Google's or Motorola's or Sony's, would work on any phone.. just another app. Things like "MotoBlur" live here. You could drop Android 2.1 in any time you like after it's released, and then add in app updates.
Yeah... I'm a little concerned about this approach. It's true that, when you violate the setup and hold times on a flip-flop, the device will go metastable for a defined period of time. The result is unpredictable, but you have more work to do to prove it's truly random... it is influenced by system noise and other stuff. That stuff could be random, but it could also not be all that random.
Way back in college, I did a "digital dice" project, in which we were told which parts to use (from the old, glorious, TI TTL Databook... I had the hardcover version), and we had to explain why it was random. In addition, they claimed there would be some noise on the power supply. I rejected that immediately... the noise wasn't likely in this kind of device, running from batteries. My trick was pretty simple. I had one timer used for the "roll"... it basically just counted for a period of time, set by an RC constant, no big magic. Then I had a second timer that ran a cycle of over a minute in time. That one modulated the frequency of the first. So, based on when and how long you pressed the "roll" button, the count was crazy variable.
I'd like that kind of thing for random numbers.. all the stuff, like human input, that has nothing to do with the device you're using. How about a super-accurate timer catching keystrokes and only looking at the LSBs? Even great musicians don't have perfect timing, even if (as a not-so-great musician), they might do better than I do. Why not factor in GPS, light sensor, WiFi RSSI, and a bunch of other "random" data you might have. Would this really be less random than what these guys did?
Easy -- the web browser itself has no business being a video decoder. It needs to call up the proper OS-resident function to play back the video in question, or fail, should that OS not have the knowledge to play that video format.
Similarly, the web browser does not need to provide a video driver, a mouse driver, an audio CODEC, a file system, a hard disc driver, a keyboard driver. These are all OS jobs. When a web browser takes on any of them, it'll at best do the job poorly.
My desktop PC can play back 1080/60p H.264 using only 12% CPU and the latest H.264 OS-resident CODEC. Why in the world would I bother with a web browser trying to do this internally and sucking up the whole machine just to play an inferior video? This is why Mozilla's idea is so very flawed... solving the video problem is not the web browser's job.
Um... VP3 was tossed out to FOSS when On2 delivered VP4. They're now at VP8. It's more like comparing H.265 to MPEG-1... you're talking ten years of additional CODEC work between VP3 and VP8.
Not that the Xiph guys haven't necessarily improved VP3 on the way to Ogg Theora. But any improvements of any kind also beg the patent question... did they step on anyone else's patents. I won't say "work" here, because these patents generally should not exist... anything as easy to re-invent on your own as 99% of all software patents does not meet the requirements of "patentable invention", IMHO anyway.
Ok, no. Their real reason for opposing H.264, and even (last I heard) using OS CODECs when available, was their goal of having a totally free browser that actually did the job. In short, they wanted to mandate Theora, because if they didn't, H.264 would become the de-facto standard. Thus, their Theora and only Theora stance... someone here suggested it's changed, but didn't post a reference.
In short, it's a religious argument, and about as crazy as other things religious people do. Mozilla isn't remotely large enough to prevent H.264 from becoming the standard. Particularly because they lack the time machine necessary to go back ten years and prevent it from happening... H.264 is already the standard. The only way to dislodge that is the way every standard eventually falls --- offer something much better. Ogg Theora is worse. You know how everyone switched from MP3 to Ogg Theora back in the mid 2000's? Remember that? Oh, sorry... that didn't happen. Ogg Theora was ever-so-slightly better than MP3, in terms of coding efficiency. It was, IMHO, better than WMA in terms of not adding annoying crap I can actually hear, like pre-echos. On the other hand, AAC was much better than MP3. And advanced by Apple, Panasonic, and a few others. Now it's supported pretty much everywhere, and while it hasn't replaced MP3, it's quite popular. Vorbis... not so much.
The only real question is whether Mozilla's going to let this argument kill off much of Firefox's recent gains. Or will they compromise, and not have that happen.
I claim they will compromise, only because, they already have. They're supporting H.264 in Fennec, using a smart phone's own H.264 CODEC... the only way to actually get video playing well on most smart phones. They need the hardware acceleration, that is correctly an OS/driver issue (on the PC too, just less so), and they seem to be approaching this correctly on the handset versions of Firefox. We'll see.. I'll be trying it out on my DROID ASAP.
Remember how IBM was so unified behind OS/2 that it caught on worldwide, and replaced Windows, and how everyone's using OS/2 nowadays. Oh wait, that didn't happen either. One piece of Mozilla not even supporting the position of Theora as the only solution and allowing (if not necessarily embracing) H.264 is much the same thing. But the mobile phone scenario actually illustrates an even stronger point: the video CODEC doesn't belong in the web browser. Anywhere in the web browser. It is today, even on a frackin' phone, part of the OS. It needs to be part of the OS, so that all of that cool video acceleration I have and you don't have works on my PC. So that improvements in video technology actually just get to improve, on or off the web, without web browser guys acting as gatekeepers. If video wants to be free, it'll win its own freedom. We don't need the Mozilla occupying force hanging around for a decade supervising this process.
Is this a recent decision? Up until about last week, Mozilla representatives were saying they were not supporting any OS-supplied CODECs, period. Despite this being stupid on multiple levels, that was the stance... their propped up argument was that OS-level CODECs... those same ones used in Windows and MacOS to create most of what you'll be playing back in Firefox... were not reliable enough for a consumer viewing experience.
Regular Dirac (versus Dirac Pro) seems to be pretty comparable to H.264, though it's current implementations are very slow, and still pretty experimenty. Dirac is open AND royalty-free, at least from the BBC's perspective. They did not file any patents on it.
It's not certain to be free of patent encumberance, though, particularly in countries, unlike the UK, where software patents reign supreme. Dirac is based on wavelets, like JPEG 2000 or the commercial CineForm CODEC. There's some claims that it will offer a higher coding efficiency at the same apparent video quality as H.264, others that claim twice the coding efficiency of MPEG-2 for HD, which puts it in the same general ballpark as H.264 (typically 2x-3x), VC-1, Theora, and other modern DCT-based CODECs.
The big problem with Dirac right now is speed.. you need a decent dual-core CPU to get smooth 720/30p playback. Being non-DCT, it's not going to get any help from the typical hardware acceleration on device, but might benefit from some of the low-level graphics card accelerations, or maybe something using OpenCL. And probably just more software optimizations. I've played around with it a bit, but then encoder was slow enough that I didn't get much joy out of it (this was using the dirac-research encoder, which is higher quality than the Schrödinger version, but also known to be slow). Quality looked great. I'm kind of partial to wavelet encoders these days, too. Maybe it's from 20+ years of staring at DCT encoded video, but it just seems to me that, even where there are artifacts, they tend to be more "organic", so you notice them less.
And this is especially profound given how well one's brain adapts... your brain learns to filter out the bad stuff in video you watch repeatedly. When I first got into digital video... ok, it still sucked, back in the 80s. And into the 90s. But after awhile, I could certainly still see DCT blocking (when you run an overly aggressive low-pass filter after DCT conversion, you start to see block boundaries when you uncompress. Try pretty much any VideoCD for examples of this, and it's still visible on DVD and HD sources, particularly HD from satellite or Comcast). But my brain did adapt... both ways. When I occasionally went back to analog, I was amazed... "how did I ever live with this crap" was the usual thought. Of course, if I spent a year watching nothing but old SVHS and Hi8 tapes, I'd start liking it ok again, and then be horrified at my DVDs. Well, ok, horrified by my TiVo Series 1. Anyway, if you look at new basic technology, like wavelet vs. DCT, and it doesn't have big visual issues, that's a very good sign you're onto something good.
Dirac Pro is being poised as a open CODEC for professional work, probably in competition with CineForm, Apple Intermediate CODEC, AVC Intra, and other professionally suited, intra-frame only CODECs. The specs are finalized, and this has been accepted by SMPTE as the VC-2 CODEC. This is not of interest for web video. I use CineForm sometimes for video editing... you need about 50GB/hour for 1440x1080/60i video in Cineform, or about 120GB/hour for 1920x1080/60p video in Cineform. I was actually looking into Dirac Pro as a replacement for Cineform (another is SMPTE VC-3, which is also called Adobe DNxHD, also intended for professional use).
Well, the idea wasn't just theirs... it was easy to guess where this might go (in fact, I was recommending the same things, even here, months ago).
The fact is, the whole tag debate isn't doing a great deal to get away from Adobe Flash being the default video player on the web (without even getting into the other stuff Flash does, some quasi useful, some terribly annoying). Google and other video streaming companies have a very legit reason for not wanting to step backwards and lose even more money switching over to Ogg Theora. The FOSS community has very valid reasons for wanting to be able to distribute a whole soup-to-nuts video-for-web solution without commercial entanglements of any kind (I soundly reject their religious convictions, like the Mozilla people not supporting OS resident video CODECs, but that invalidate the correct part of their argument).
So, Google owns the largest video streaming site on the planet. It currently runs a mix of older Flash video (On2 VP6) and current H.264 video. Their main expenses are streaming.. they pay for bandwidth, and it's rare for anyone doing that with video right now to not be losing money. Google did just buy On2, a company that's been in this video-on-the-web market for over a decade, same company who tossed out their old technology, VP3, to the open source community, providing the foundation for Ogg Theora. And they have a new video CODEC, VP8, that claims to offer up to 40% better coding efficiency than H.264 at lower bandwidths.
Gee... what could Google be thinking here? If this is all true about VP8, and they could get this into a browser, I bet they'd save a bundle, even if they just offer VP8 over H.264. Oh, and wait, Google has this thing called Chrome... a browser. They could use VP8 to get you to upgrade to Chrome for YouTube, or maybe just give away VP8 as a way to make everyone suck less bandwidth from Google. I haven't seen any numbers on their YouTube division's profit and loss, but this would absolutely tilt the balance toward "profit".
Now, enter the FSF's request... that's not all that outlandish. After all, Google spent about $50 million to buy then 2-year-old Android, Inc. in 2005. And then they released it all as Open Source. Their motivation was simple: prevent proprietary OSs from taking over on the handset... and thus, taking over the all-critical search function on the handset. So there's precedent... they pretty much gave away everything here, and in doing so, they may have built the future-dominant handset OS. They also seem to have pushed others toward open sourcing their OSs, just to compete... as Nokia did recently with the Symbian OS (currently about 50% of the worldwide smart phone market). With VP8, Google would presumably just be releasing a piece of what they bought with On2, albeit perhaps a crown jewel.
But with Google's business model, it's not likely they're going to sell VP8 encoders, or whatever. The usual "Google thing to do" would be to use this technology to boost their existing business somehow. So a free VP8, assuming it really can be free (there's always the potential for outside patents covering the work they've done), seems even kind of likely. Wow... the FSF actually doing something that doesn't seem crazy? Or have they finally stolen my mind?
No. "Proprietary" means you can't implement the spec, because there is no spec. It's a privately held design, and your only choice is reverse engineering. This has absolutely nothing to do with patent encumberances... there are plenty of proprietary formats that are closed just because their creators want them closed -- no other means of keeping them closed but secrecy. Some countries actually protect the right to reverse engineer such things for the purpose of compatibility. The whole issue here really has nothing to do with patents.
"Open" means that it's an agreed-up industry standard, and anyone can get a copy of this spec and create a device or program that implements that spec. Similar "open" standards including SMPTE AC-3, SMPTE VC-1, IEEE 802.11, IEEE 802.3, IEEE 1394, IEEE 1284, PCI, USB, PCI Express, the IBM PC architecture (though VESA), etc. Some of those have currently valid patents, on some, the patents expired, on others, you have to license the patents.
But the need to license has nothing to do with whether the spec is open, and openness has nothing to do with any need to license. "Open" is the availability of information about the thing or not, not whether some of it's still owned by someone. All FOSS code is open, in the sense that you can get access to all of the source code. But ownership varies. You have the BSD model, which is public domain... no one owns the code at all, you can do whatever you want with it. Then you have various public licenses... someone else owns the code, and as such, you are required to follow the terms of their license. Now sure, the GPL was designed to force things to remain open, but there's still an owner. That owner won't necessarily always keep the source open.
And it's also quite possible there are patents... that's been a big debate, and a constant way for anti-FOSS folks to spread FUD, as both Microsoft and SCO have previously done. GNU projects try to ensure there is nothing patented in FOSS code, but they also don't usually employ an army of lawyers checking it over. Anti-FOSS folks sometimes do.
My point being, these are and always will be separate issues. And they're important ones. The basic H.264 patents run out 2023ish... the last somewhere around 2025-2028, depending on how much fear mongering is going on. After that, it's open, free, standard, and clear. If the VP8 patents ran out tomorrow, it wouldn't help anyone, because no one outside of On2 has much of an idea of how VP8 is implemented. That's the salient different between "open" and "closed" specifications.
Slashdot Mirror
Yeah... open source alone is not always an important figure of merit if you have real work to do.
But you need to flip it around. GNU/Linux is very, very useful, and this largely because all these developers already understood how useful UNIX was, as used that as the basis for GNU/Linux. It is the case that "already proven good" + "open source" >> "already proven good", at least for most values of "always".
There are a few very useful media container formats around: MPEG-2 TS (ITU-T Rec. H.222.0), QuickTime, MPEG-4 (SO/IEC 14496-14), Matroska, going all the way back to IFF on the Amiga (and of course, that one 100% free and clear to clone and extend at will.. 1985 wasn't exactly a banner year for computer video). As much as it's often said that those who don't understand UNIX are doomed to recreate it, poorly, there's absolutely no question this is true of something as relatively simple to get right and painful when wrong as a media container format. The very simple ability to add a new format, and for a reader/player/editor to ignore formats it doesn't know, is one fundamental requirement. Other useful requirements include the ability to stream well... both reasons MPEG-2 TS still dominates in transmitted media (television, satellite, DVD & Blu-Ray, etc).
That's not to suggest MPEG-2 TS is ideal (it was written for hardware decoders, but, then again, tools to deal with TS streams abound already in all modern OSs). Or Amiga IFF, or Quicktime/MP4. Patent-wise, the MP4 file format was derived directly from the Quicktime (.mov) file format, which dates back at least to the early 1990s. So even if Apple has patents, they can't be all that long lived. But Ogg does things in stupid ways that were long ago handled much better by these other formats. It's pretty clear that the Ogg format creators were solving the short-term goal of encapsulating Vorbis, and subsequent projects should have dumped it in favor of something else.
And in particular, why not support Matroska? This is a very well done media container format. It's an open standard, and the libraries are licensed on LGPL, with parsers and player libraries under the BSD license. There's growing support for Matroska in software media players, hardware devices (TVs, Blu-Ray players), etc. And no known patent entanglements, just like Ogg. NIH maybe? The Theora and Vorbis people don't like Russians?
Brown isn't fugly, it's a great color. The color of my hair, my guitar, and my Zune. The color of my coffee, the color of chocolate. The color of Halle Berry.
OSX in metallic... yeah, I didn't get enough of that in Linux in the early 1990s. Looks horribly dated. Windows 7 is something of an improvement over XP, mainly because they removed the annoying and distracting candy-coloring or everything, and used "translucent" to make the theme virtually neutral.. change your background, and you're good to go. Same reason most professional media content software uses neutral greys for much of the interface: let's not distract one away from the actual use of the system.
Brown worked in this pretty well, too. Purple, not so much.
..ah say, what profession, deems brown unprofessional and orange and aubergine professional? Are they serious?
Yes, clearly, the color scheme has been holding Ubuntu back... riiighhhtt. And if they're changing it, couldn't they choose a background that says something to me other than "dude, your monitor needs degaussing"... yeah, I'm on LCDs too, but that background has to go.
Pond liners are generally made of plastics that can easily 50 years in sun (albeit some of it attenuated by water, in varying degrees). It's a truth that most plastics break down over time in the sun, it's generally a sad thing that many take a good thousand years to do so, even when not engineered for long life in the sun.
Doubled-plus. Sure, there are 40% efficient solar panels, if you have a satellite or space probe budget. Others are more like 20%, and when you're talking about super cheap panels, 10% is kind of a magic number. On the ground, 20%-ish for conventional or 10%-ish for super-cheap is already on-par, long-term, with other energy sources. If these really achieve 86% efficiency and don't cost a bloody fortune, this is revolutionary. Holy balls indeed!
Hmm... yeah. He's not sensitive to the guy's cellphone before the call, even though that phone is transmitting beacons all the time, to remain in contact with the local tower. Sounds like a nut. I did read the article, but it was just about this guy, and didn't offer any real critique. They should have sent a reporter out there with a 2-something GHz "white noise" generator in hit pocket. Or better still, do a real double-blind test. If the guy's actually sensitive to higher UHF spectrum RFI, that would be pretty interesting. Far as anyone knows, this stuff can't be detected by biological critters in any way. Some critters do, however, detect magnetic fields.
Well, part of the problem is that these systems all started out, ten or so years ago, as "clones" of TiVo... or at least efforts to replicate what TiVo did well. Microsoft did likewise with their Media Center shell. And the big problem they all had, and some still have, is stability. You still you're you're using a PC, not an appliance. Most of us here don't find that to be a huge problem, but the average TV viewer doesn't want or need PC-like issues to get the way of their TV viewing.
No crashing, no missing shows (in ten years, the only time my TiVo misses a recording, other than during power outs, was when the IR blaster wasn't seen by the STB correctly -- a problem with the STB, really.. other STBs allow serial connections that never fail this way). If I yank the plug on a DVR, I can't have a 5 minute startup while the device CHKDSKs or fscks... it has to be ready, immediately. It has to run quiet and cool... no heating up in an enclosed cabinet (the PS3 fails this, but it doesn't have to remain on).
And of course, regular consumer guy has to have a way to buy it, as an appliance. Sure, I could set these up for people easily enough, but at some point, you really find you're already doing enough free IT work for friends and family on their computer systems... you don't want to ask for more of that if you can help it. I have yet to see any of these systems work as reliable as I'd need for a consumer product.
Increasingly, there's no functional difference between "televison" and "computer video display". I'm on my fourth television with VGA inputs. Just about any TV these days supports HDMI input... HDMI is a superset of DVI-D... so pretty much any digital TV can display HD computer video. Going the other way, many of the new cheap LCD monitors are made using panels originally designed for TVs (hint: the computer standard is 16:10, the video standard is 16:9... all those cheap 1920x1080 monitors are really using TV panels).
And really, what's the difference once you're digital... is there anything particularly different when the TiVo makes an HD image using a DVB-HD SOC, rather than your TV doing it with an ATSC SOC, your PS3 making it with its dedicated graphics chip, or your PC doing it with nVidia or AMD/ATi graphics? A video signal is a video signal, there days.
I have monitors here, from the new Westinghouse company. They're on 16:10, 1920x1200 MVA panels, so very computer-industry. No turner, either. But they support HDMI rather than DVI, including audio over HDMI, so you can use these for stand-alone video playback. Plus, they support VGA, YPrPb, S/V and CVBS analog inputs... so you can connect up practically any video device made in the last 50 years and get an upconverted picture.
One of my kids has a 28" LCD TV, but it does a full 1080p image, and looks great as a computer monitor. And in fact, the same company (Hann) makes the identical screen in the same plastic, without the tuner and with a DVI input, and sells it as a monitor.
The "monitor vs. TV" thing is really not much of a question anymore. You probably find that for TV use, there's at least a mode (on an LCD display) for dynamic contrast (native LCD contrast is usually 1000:1 or so, CRT-based TVs offer at least 10,000:1)... for computer use, there's a mode that guarantees 1:1 pixel mapping, not always the default on a TV, even a digital one.
It actually kind of is. The recording is trivial, since, when you're "recording" HD, you're just recording the MPEG-2 transport stream to HDD, rather than actually creating an MPEG-2 data stream. This is going to a maximum of 19.4Mb/s per channel recorded, which is no big deal given the 30-50MB/s writes a modern HDD can support.. you just need enough buffering to not get killed by seek times. For playback, they're all using MPEG-2 or perhaps MPEG-4 decoder chips, designed for appliances like set-top boxes or Blu-Ray players. That's actually the big computational element, but all in hardware... so playback is only fetching the fairly low bitrate transport streams, anyway.
The only problem a PC had with this is the playback... if you're decoding full 1080/60i or 720/60p HD in MPEG-4, you basically need two CPU cores per stream. Or very good GPU acceleration (I can do a 1080/60p stream on my Q9550 machine with about 12% using a nVidia 8800GT with DVXA 2.0 acceleration.. that goes to about 60% playing back in VLC). But the big win using hardware decode is power. Even with simpler CPUs, like in the PS3, you run up to 250W as a player, versus maybe 25W for a dedicated Blu-Ray device. Obviously, home-made DVR-PCs cover this range, and beyond, depending on how much work you give them.
TiVo originally offered the lifetime subscription... I have this on my first TiVo box. It's a good investment, given this TiVo is around 10 years old, but also because it lowered the monthly fee on the second box. Since the very early days, TiVo has sometimes offered the lifetime subscription, sometimes not, sometimes allowed transfers (eg, when pushing Series 3 hardware to Series 1 owners like me... unfortunately, doesn't work with satellite HD), etc. So depending on when you bought a TiVo, lifetime subs were not always an option.
The PS3 isn't quite a TiVo replacement. Sure, you can download videos.. that was a retrofit into the TiVo, but it's also a pretty standard feature of most 2010-vintage dedicated Blu-Ray players. I suggest that "plays Netflix" is even more of a check-mark feature in modern set-top devices than "DVR" is today.
The PS3 is also a generally better video jukebox than a TiVo... it plays more video formats (ok, I haven't spent much time with a "Series 3"), it streams video over wireless or wired Ethernet without hacks or slowdowns, and in particular, it supports external storage, very easy internal drive upgrades, and built-in backup support to external media. In fact, the instructions for HDD upgrade were in the manual, at least when I got my PS3.
But the PS3 is not a functional time-shifting device... no way to record video.
ATSC broadcast is 19.4Mb/s in the USA, which is the limit on 1080/60i or 720/60p that's broadcast. Usually, the OTA broadcaster will have an SD aux channel or two.. these are typically 2-3Mb/s. So you might expect 15-17Mb/s in practice, OTA. Going to H.264 should give you the same quality at 6-9Mb/s, depending on the material and the encoder. That's kind of the practical upper bound for broadcast.. Blu-Ray videos are generally much higher bitrate. On the low end, YouTube does 720/24-30p video at 2Mb/s, and Netflix varies from 2.8-3.6Mb/s on their HD (all 720p as well) videos, but they're using the somewhat less efficient SMPTE VC-1 (Windows Media 9) CODEC.
So realistically, streaming two HD channels at broadcast quality over your home broadband? Not happening in most homes, even if the net itself were not the bottleneck. This is why TV providers are not using an IPTV model for, well, any real video.
H.264 offers 2x-3x the coding efficiency of MPEG-2, when done very, very well. If you're taking a source well rendered to MPEG-2 at 6Mb/s and MPEG-2 (assume SMPTE AC-3 audio for both) down to 1.5GB/hr, you are losing quality.
For broadcast quality (1080/60i or 720/60p), you're still talking 10-12GB/hour for MPEG-2, and no less than 3-4GB/hour for very well rendered H.264. Some of the render-on-the-fly stuff for H.264 is still lacking (eg, the encoding has been rapidly evolving, MPEG-2 pretty much a done deal), so for unit quality, you're more likely to see 5-10GB/hr for AVC at the same resolutions. Of course, cable and satellite companies have no problem compromising quality, and on the internet, they first thing anyone does is cut the source down to 720/24-30p.
As for live streaming, no, latency isn't that important... it's not as if there's enough storage in any video pipeline for crazy latency issues anyway. Now, you're talking about interactive video, that's where the latency becomes a real issue. And there are even ways to trick-play around that, if there's need.
TiVo, and nearly at the same time, Replay, popularized devices designed entirely for time-shifting... call 'em PVR or DVR, same thing. Basically, while a VCR could do this, it was ill suited to it -- serial storage, a maximum of 8hr of recording time if you'll accept the heinous qualify of EP recording on extra long tapes.
This worked fairly well over-the-air or to an analog satellite or cable box.. I still have two TiVos in my house. As a technology, they did some smart things. The user interface was so bloody easy, folks with flashing "12:00" on their VCR might actually manage to use the device (particularly if they got your average 14 year old to help wire it up). They didn't just merge EPG and VCR, they figured out why that's a synergy -- you could "subscribe" to a season of a show, non-specific about the time. And the TiVo would track your viewing habits and auto-record extra stuff.. still one of the best features.
There were two big problem, though. First was the ascendancy of pay TV, Digital, and DRM on video. Anyone can make an ATSC receiver for OTA digital TV, but (in the USA, not everywhere) cable and satellite were both proprietary. So no easy path to an HD TiVo that works as well as SD TiVo did on SD video. TiVo didn't want to add the expense of encoding analog or unprotected HDMI to MPEG or whatever HDD format they wanted, and yet, without access to your cable or satellite bitstream, they couldn't simply save that existing bitstream. There was lots of politics going around to standardized on DRM and cable hardware independently of cable provider, but the cable companies really didn't want this. They ultimately were forced (1996 Telecom Law) to accept what became the somewhat sabotaged CableCARD standard (used on the HD TiVo), but begrudgingly at best (a good lesson in the doublethink of forcing an industry to create the technology they don't want in the first place). And even once it finally materialize, many services made it hard to get one, they screwed around with how it worked, and generally made you feel second class, versus using a cable box directly. And there's no such option for satellite.
But the big thing... the basic PVR idea is not difficult to build into a digital device, particularly if you're already a digital receiver with a bitstream that can be tapped. I was designing an "advanced" set-top box with a German startup company I co-founded (Metabox AG) back in 1998-2000, and we did this. You have a DVB tuner and decoder, at some point there's an MPEG-2 transport stream, which you split to get the channel you're after (there can be up to 32 channels in a single transport stream). So, rather than sending that to the MPEG-2 decoder, you save it on disc. Add some smarts around that, and you get a PVR for the price of a hard disc... much easier than in the analog days, having to do the encoding.
That's really the problem TiVo got hit with... this is just a new feature to add to STBs for cable and satellite. I haven't seen any quite as user-friendly as TiVo, but on the other hand, I'm a computer wizard.. I really don't need all that much hand-holding. My Dish ViP 622 is slightly harder to use than a TiVo, but it seems a little less arduous as well. Now, Dish didn't get this right from the get-go... they inflicted some of history's worst PVRs on their customers before getting it decent. But the ViP 622 is just dandy... 2 sat and 1 OTA channels recording in HD while one HD and one SD can play back. That doesn't suck. Or the fact it can tap HDDs up to 1TB for external storage, offloading of video you need to keep around for awhile.
This was inevitable, once the TV "player" became digital. TiVo got popular, satellite and cable companies used "it's like TiVo" to offer you a "free" device (with 2-year contract) rather than your having to buy one. And they often make it free, too... after all, you're already paying for the EPG. Satellite really had to make these very good, to have any hope of competing with cable on things like on-demand video. Cable in turn added it to com
Ok, so I live on a tree farm in South Jersey. For some reason we're getting mad snows this season, rather than the usual 1"-then-melt situation. So, I'm at Sears early last month, loading a "Craftsman Professional" snowblower in to the back of my pickup. I jump down from the tail gate... DROID keeps going. Ouch!
Apparently, it landed and bounced... I had crawl under the truck to find it. But not only did it survive... not a scratch. I am not kind to mobile hardware in general, and I did have insurance on it, but damn... DROID DOESn't BREAK!
Of course, I should add, with 2.6x more pixels to paint, a DROID or Nexus One, even with a faster GPU, might well lose a frame-per-second race against an iPhone 3GS.
Well, the iPhone 3GS sure outperforms the older PowerVR MBX-Lite use in all previous iPhones. The MBX-Lite used in the older iPhones does about 1Mpolys/second at the iPhone's 50-60MHz GPU clock speed.
Some real benchmarks: Tap Tap (a big iPhone developer) found the 3GS about 4x faster in 3D applications:
http://www.taptaptap.com/blog/iphone-3gs-blows-away-iphone-3g-in-3d/
There is a THEORY that the GPU is an underclocked PowerVR SGX 535 (Intel calls this the GMA500), largely based on some #defines in the Apple SDK. And also because they include the VXD370 media accelerator, which has usually been coupled with higher-end SGXs. Of course, TI didn't need this, they have had their own media acceleration technology going back to before the DaVinci SOCs (what you find in most higher-end PMPs going back some years). This is a chip custom-made for Apple by Samsung, so in truth, unless Apple's talking, we may not know. The Anandtech article also postulates the SGX 520, but again, any number of core + clock speed combinations lead to the same answer.
http://www.anandtech.com/gadgets/showdoc.aspx?i=3579
But a full SGX 535 runs at 200MHz and does 28 MPolys/s. Pretty good chance that's not what the iPhone 3GS is running -- there are no benchmarks showing even half of that performance. Most benchmarks show the 3GS running 3x to 7x faster at 3D, an assuming the faster CPU isn't part of that, you could get with an SGX 535 at 50MHz, an SGX 530 at 100MHz, or an SGX 520 at 200MHz. The real answer might be known to developers: the SGX 520 has a single Universal Scalable Shader Engine (USSE) pipeline, the others add multiple pipelines for additional performance. Not that you'd necessarily have this exposed in OpenGL.
It is not debatable about the DROID/Milestone.. it contains OMAP 3430, which contains the PowerVR SGX 530 GPU core. TI quotes a peak of 10Mpolys/sec. which this chip at normal clock speeds; it's programmable, typically run in the 100-160MHz range (14Mpolys/sec is the peak you can expect with 200MHz clock). Of course, there are all sorts of folks boosting their DROID to much higher clock speeds, but this what you'd expect in stock performance. And it's quite possible there are still optimization issues in Android that no longer apply to the slightly more mature iPhoneOS.
App upgrades are actually handled just dandy.. at least in the Android Market. Anything you downloaded via Android Market will show up, once updated in the market, as a notification of a new app. In fact, it's better than Windows and as good as Linux... as long as you got all your Linux apps via update-manager or something similar. It works, and it's properly centralized. As opposed to Windows, where, if you're not careful, you'll wind up with a few dozen "check for update" daemons. Yuk.
Far the OS ... yeah, they screwed the pooch on this. The problem is not understanding the process of OS release, but not understanding the fact that phone and CE companies don't have much of a clue about dealing with application processing platforms. If you got a DVD player back in the 1990s, there's a good chance it didn't support DVD-R, and worse yet, DVD+R. But this was not usually a shortcoming of the hardware design, but rather, bugs in the DVD reference code. I have a Pioneer DVD player around here somehere, not based on the Toshiba/DVD Forum reference code, which worked with all of those new formats. The CE companies simply looked upon this as a way to sell new DVD players.
With all that's evil about Apple these days, their distant personal computer heritage has them smart about OS upgrades. So virtually any iPhone can run the latest iPhoneOS. That's easier when you're centrally managed, but not that hard otherwise.
The key to this kind of upgrade is a truly modular OS. That's kind of the anthesis of Linux thinking... it wasn't all that long ago when "rebuild the kernel to add that new device" was kind of the answer to that thing you just added to your PC. Android really should have had a number of independent modules.
Module #1 is the HAL (hardware abstraction layer). Motorola and HTC author HALs, and build them into the smartphone,This is a standard, low-level interface to each chunk of hardware, done in a standard way. Nothing as complex as a device driver, this is basically a plug: storage devices all look the same, cameras, screens, etc.
Module #2 is the OS. This comes from Google. Using the HAL, every device can drop in that OS... it essentially plugs into the HAL on every phone. This would largely eliminate the need to make OS upgrades the hardware company's problem. New hardware supported in the OS would simply not mate with HAL objects.. no problems. Google pushed out 2.1 (or any other developer) and you can drop that new binary into any phone, with memory limits.
Module #3 is all apps. So the "home" screen, whether Google's or Motorola's or Sony's, would work on any phone.. just another app. Things like "MotoBlur" live here. You could drop Android 2.1 in any time you like after it's released, and then add in app updates.
Yeah... I'm a little concerned about this approach. It's true that, when you violate the setup and hold times on a flip-flop, the device will go metastable for a defined period of time. The result is unpredictable, but you have more work to do to prove it's truly random... it is influenced by system noise and other stuff. That stuff could be random, but it could also not be all that random.
Way back in college, I did a "digital dice" project, in which we were told which parts to use (from the old, glorious, TI TTL Databook... I had the hardcover version), and we had to explain why it was random. In addition, they claimed there would be some noise on the power supply. I rejected that immediately... the noise wasn't likely in this kind of device, running from batteries. My trick was pretty simple. I had one timer used for the "roll"... it basically just counted for a period of time, set by an RC constant, no big magic. Then I had a second timer that ran a cycle of over a minute in time. That one modulated the frequency of the first. So, based on when and how long you pressed the "roll" button, the count was crazy variable.
I'd like that kind of thing for random numbers.. all the stuff, like human input, that has nothing to do with the device you're using. How about a super-accurate timer catching keystrokes and only looking at the LSBs? Even great musicians don't have perfect timing, even if (as a not-so-great musician), they might do better than I do. Why not factor in GPS, light sensor, WiFi RSSI, and a bunch of other "random" data you might have. Would this really be less random than what these guys did?
Easy -- the web browser itself has no business being a video decoder. It needs to call up the proper OS-resident function to play back the video in question, or fail, should that OS not have the knowledge to play that video format.
Similarly, the web browser does not need to provide a video driver, a mouse driver, an audio CODEC, a file system, a hard disc driver, a keyboard driver. These are all OS jobs. When a web browser takes on any of them, it'll at best do the job poorly.
My desktop PC can play back 1080/60p H.264 using only 12% CPU and the latest H.264 OS-resident CODEC. Why in the world would I bother with a web browser trying to do this internally and sucking up the whole machine just to play an inferior video? This is why Mozilla's idea is so very flawed... solving the video problem is not the web browser's job.
Um... VP3 was tossed out to FOSS when On2 delivered VP4. They're now at VP8. It's more like comparing H.265 to MPEG-1... you're talking ten years of additional CODEC work between VP3 and VP8.
Not that the Xiph guys haven't necessarily improved VP3 on the way to Ogg Theora. But any improvements of any kind also beg the patent question... did they step on anyone else's patents. I won't say "work" here, because these patents generally should not exist... anything as easy to re-invent on your own as 99% of all software patents does not meet the requirements of "patentable invention", IMHO anyway.
Ok, no. Their real reason for opposing H.264, and even (last I heard) using OS CODECs when available, was their goal of having a totally free browser that actually did the job. In short, they wanted to mandate Theora, because if they didn't, H.264 would become the de-facto standard. Thus, their Theora and only Theora stance... someone here suggested it's changed, but didn't post a reference.
In short, it's a religious argument, and about as crazy as other things religious people do. Mozilla isn't remotely large enough to prevent H.264 from becoming the standard. Particularly because they lack the time machine necessary to go back ten years and prevent it from happening... H.264 is already the standard. The only way to dislodge that is the way every standard eventually falls --- offer something much better. Ogg Theora is worse. You know how everyone switched from MP3 to Ogg Theora back in the mid 2000's? Remember that? Oh, sorry... that didn't happen. Ogg Theora was ever-so-slightly better than MP3, in terms of coding efficiency. It was, IMHO, better than WMA in terms of not adding annoying crap I can actually hear, like pre-echos. On the other hand, AAC was much better than MP3. And advanced by Apple, Panasonic, and a few others. Now it's supported pretty much everywhere, and while it hasn't replaced MP3, it's quite popular. Vorbis... not so much.
The only real question is whether Mozilla's going to let this argument kill off much of Firefox's recent gains. Or will they compromise, and not have that happen.
I claim they will compromise, only because, they already have. They're supporting H.264 in Fennec, using a smart phone's own H.264 CODEC... the only way to actually get video playing well on most smart phones. They need the hardware acceleration, that is correctly an OS/driver issue (on the PC too, just less so), and they seem to be approaching this correctly on the handset versions of Firefox. We'll see.. I'll be trying it out on my DROID ASAP.
Remember how IBM was so unified behind OS/2 that it caught on worldwide, and replaced Windows, and how everyone's using OS/2 nowadays. Oh wait, that didn't happen either. One piece of Mozilla not even supporting the position of Theora as the only solution and allowing (if not necessarily embracing) H.264 is much the same thing. But the mobile phone scenario actually illustrates an even stronger point: the video CODEC doesn't belong in the web browser. Anywhere in the web browser. It is today, even on a frackin' phone, part of the OS. It needs to be part of the OS, so that all of that cool video acceleration I have and you don't have works on my PC. So that improvements in video technology actually just get to improve, on or off the web, without web browser guys acting as gatekeepers. If video wants to be free, it'll win its own freedom. We don't need the Mozilla occupying force hanging around for a decade supervising this process.
Is this a recent decision? Up until about last week, Mozilla representatives were saying they were not supporting any OS-supplied CODECs, period. Despite this being stupid on multiple levels, that was the stance... their propped up argument was that OS-level CODECs... those same ones used in Windows and MacOS to create most of what you'll be playing back in Firefox... were not reliable enough for a consumer viewing experience.
Regular Dirac (versus Dirac Pro) seems to be pretty comparable to H.264, though it's current implementations are very slow, and still pretty experimenty. Dirac is open AND royalty-free, at least from the BBC's perspective. They did not file any patents on it.
It's not certain to be free of patent encumberance, though, particularly in countries, unlike the UK, where software patents reign supreme. Dirac is based on wavelets, like JPEG 2000 or the commercial CineForm CODEC. There's some claims that it will offer a higher coding efficiency at the same apparent video quality as H.264, others that claim twice the coding efficiency of MPEG-2 for HD, which puts it in the same general ballpark as H.264 (typically 2x-3x), VC-1, Theora, and other modern DCT-based CODECs.
The big problem with Dirac right now is speed.. you need a decent dual-core CPU to get smooth 720/30p playback. Being non-DCT, it's not going to get any help from the typical hardware acceleration on device, but might benefit from some of the low-level graphics card accelerations, or maybe something using OpenCL. And probably just more software optimizations. I've played around with it a bit, but then encoder was slow enough that I didn't get much joy out of it (this was using the dirac-research encoder, which is higher quality than the Schrödinger version, but also known to be slow). Quality looked great. I'm kind of partial to wavelet encoders these days, too. Maybe it's from 20+ years of staring at DCT encoded video, but it just seems to me that, even where there are artifacts, they tend to be more "organic", so you notice them less.
And this is especially profound given how well one's brain adapts... your brain learns to filter out the bad stuff in video you watch repeatedly. When I first got into digital video... ok, it still sucked, back in the 80s. And into the 90s. But after awhile, I could certainly still see DCT blocking (when you run an overly aggressive low-pass filter after DCT conversion, you start to see block boundaries when you uncompress. Try pretty much any VideoCD for examples of this, and it's still visible on DVD and HD sources, particularly HD from satellite or Comcast). But my brain did adapt... both ways. When I occasionally went back to analog, I was amazed... "how did I ever live with this crap" was the usual thought. Of course, if I spent a year watching nothing but old SVHS and Hi8 tapes, I'd start liking it ok again, and then be horrified at my DVDs. Well, ok, horrified by my TiVo Series 1. Anyway, if you look at new basic technology, like wavelet vs. DCT, and it doesn't have big visual issues, that's a very good sign you're onto something good.
Dirac Pro is being poised as a open CODEC for professional work, probably in competition with CineForm, Apple Intermediate CODEC, AVC Intra, and other professionally suited, intra-frame only CODECs. The specs are finalized, and this has been accepted by SMPTE as the VC-2 CODEC. This is not of interest for web video. I use CineForm sometimes for video editing... you need about 50GB/hour for 1440x1080/60i video in Cineform, or about 120GB/hour for 1920x1080/60p video in Cineform. I was actually looking into Dirac Pro as a replacement for Cineform (another is SMPTE VC-3, which is also called Adobe DNxHD, also intended for professional use).
Well, the idea wasn't just theirs... it was easy to guess where this might go (in fact, I was recommending the same things, even here, months ago).
The fact is, the whole tag debate isn't doing a great deal to get away from Adobe Flash being the default video player on the web (without even getting into the other stuff Flash does, some quasi useful, some terribly annoying). Google and other video streaming companies have a very legit reason for not wanting to step backwards and lose even more money switching over to Ogg Theora. The FOSS community has very valid reasons for wanting to be able to distribute a whole soup-to-nuts video-for-web solution without commercial entanglements of any kind (I soundly reject their religious convictions, like the Mozilla people not supporting OS resident video CODECs, but that invalidate the correct part of their argument).
So, Google owns the largest video streaming site on the planet. It currently runs a mix of older Flash video (On2 VP6) and current H.264 video. Their main expenses are streaming.. they pay for bandwidth, and it's rare for anyone doing that with video right now to not be losing money. Google did just buy On2, a company that's been in this video-on-the-web market for over a decade, same company who tossed out their old technology, VP3, to the open source community, providing the foundation for Ogg Theora. And they have a new video CODEC, VP8, that claims to offer up to 40% better coding efficiency than H.264 at lower bandwidths.
Gee... what could Google be thinking here? If this is all true about VP8, and they could get this into a browser, I bet they'd save a bundle, even if they just offer VP8 over H.264. Oh, and wait, Google has this thing called Chrome... a browser. They could use VP8 to get you to upgrade to Chrome for YouTube, or maybe just give away VP8 as a way to make everyone suck less bandwidth from Google. I haven't seen any numbers on their YouTube division's profit and loss, but this would absolutely tilt the balance toward "profit".
Now, enter the FSF's request... that's not all that outlandish. After all, Google spent about $50 million to buy then 2-year-old Android, Inc. in 2005. And then they released it all as Open Source. Their motivation was simple: prevent proprietary OSs from taking over on the handset... and thus, taking over the all-critical search function on the handset. So there's precedent... they pretty much gave away everything here, and in doing so, they may have built the future-dominant handset OS. They also seem to have pushed others toward open sourcing their OSs, just to compete... as Nokia did recently with the Symbian OS (currently about 50% of the worldwide smart phone market). With VP8, Google would presumably just be releasing a piece of what they bought with On2, albeit perhaps a crown jewel.
But with Google's business model, it's not likely they're going to sell VP8 encoders, or whatever. The usual "Google thing to do" would be to use this technology to boost their existing business somehow. So a free VP8, assuming it really can be free (there's always the potential for outside patents covering the work they've done), seems even kind of likely. Wow... the FSF actually doing something that doesn't seem crazy? Or have they finally stolen my mind?
No. "Proprietary" means you can't implement the spec, because there is no spec. It's a privately held design, and your only choice is reverse engineering. This has absolutely nothing to do with patent encumberances... there are plenty of proprietary formats that are closed just because their creators want them closed -- no other means of keeping them closed but secrecy. Some countries actually protect the right to reverse engineer such things for the purpose of compatibility. The whole issue here really has nothing to do with patents.
"Open" means that it's an agreed-up industry standard, and anyone can get a copy of this spec and create a device or program that implements that spec. Similar "open" standards including SMPTE AC-3, SMPTE VC-1, IEEE 802.11, IEEE 802.3, IEEE 1394, IEEE 1284, PCI, USB, PCI Express, the IBM PC architecture (though VESA), etc. Some of those have currently valid patents, on some, the patents expired, on others, you have to license the patents.
But the need to license has nothing to do with whether the spec is open, and openness has nothing to do with any need to license. "Open" is the availability of information about the thing or not, not whether some of it's still owned by someone. All FOSS code is open, in the sense that you can get access to all of the source code. But ownership varies. You have the BSD model, which is public domain... no one owns the code at all, you can do whatever you want with it. Then you have various public licenses... someone else owns the code, and as such, you are required to follow the terms of their license. Now sure, the GPL was designed to force things to remain open, but there's still an owner. That owner won't necessarily always keep the source open.
And it's also quite possible there are patents... that's been a big debate, and a constant way for anti-FOSS folks to spread FUD, as both Microsoft and SCO have previously done. GNU projects try to ensure there is nothing patented in FOSS code, but they also don't usually employ an army of lawyers checking it over. Anti-FOSS folks sometimes do.
My point being, these are and always will be separate issues. And they're important ones. The basic H.264 patents run out 2023ish... the last somewhere around 2025-2028, depending on how much fear mongering is going on. After that, it's open, free, standard, and clear. If the VP8 patents ran out tomorrow, it wouldn't help anyone, because no one outside of On2 has much of an idea of how VP8 is implemented. That's the salient different between "open" and "closed" specifications.