I'm still amazed that they actually use the same ancient machines to do it. I mean, dear god, even if the hourly fees and hardware cost were completely jacked up to outrageous levels, you could probably hire a consultant to make an Asterisk-based system with multiple layers of hardware redundancy to do the exact same thing (wait for ring, answer, announce the current time & temperature, then hang up) for less than it probably cost to lease and maintain those old machines for one year...
It's funny you mention IBM, because the BellSouth Simon (the first true wireless PDA, sold by BellSouth in 1992) was made by IBM. Its text input system guessed the 6 most likely letters and displayed them on a touchscreen, with another spot in the middle to go to the next 6 guesses if none of them were relevant. It's hard to describe its logic, but after playing with it for about an hour, you actually DID start to figure it out subconsciously and learn how many times you'd have to tap the center spot & which one of the 6 spots would have the letter you need.
>What was chinas next-gen format called now again? I would assume their players will be cheap:)
Reading the tea leaves... I'll call it "DVD+HD". Red-laser players, HD-DVD format, $89 at Wal Mart this Christmas. Not as good as HD-DVD, but an improvement over SD-DVD, and likely to be warmly embraced by porn due to having plenty of space for an hour and a half of 720p60 with 224kbit audio. At worst, they'll handle two hours of 720p24, and might even be able to do 1080p24.
It'll be a stopgap format, but it'll kill Blu-Ray dead. Why? Because HD-DVD players will be able to play DVD+HD just fine, but Blu-Ray won't. Remember, HD-DVD players are perfectly willing to play back a 9-gig disc that's mastered like a "real" HD-DVD. So HD-DVD can spend the next 2-5 years limping along and licking its wounds while "DVD+HD" becomes entrenched, then re-emerge as a premium format once the market for videophile-grade discs grows a bit larger. Since Blu-Ray players can't, by design, play anything besides Blu-Ray discs (specifically, there's no such thing as a 9-gig Blu-Ray disc), it has no "Plan B". Blu-Ray will either succeed 100%, end up as a de-facto second format that everything is compatible with (a-la DVD+R and DVD-R), or fades into obscurity after losing to a guerrilla format like "DVD+HD" with no backup plan.
In America, at least, BPL is a political smokescreen. The REAL goal of power companies is to just hang fiber from the poles they already have. However, if they came out and said, "we want to run fiber everywhere our power lines go," the phone and cable companies would have gone berserk. So they pretended instead that they really intend to do something that would be utterly insane on both engineering and accounting grounds, in the hope that once they get the OK, they can roll it out, start interfering with radio (assuming they can even get the network part to actually work reliably), then when the complaints come rolling in, generously volunteer to ditch the whole thing and run fiber instead.
Sound Quality was improved at both ends
on
The CD Turns 25 Today
·
· Score: 4, Interesting
The most surprising thing I discovered during the mid-90s (before recordable CDs were ubiquitous) was how good metal tape with DBX or Dolby C could sound. The biggest revolution brought about by CDs wasn't at the home side, it was at the production side. Pre-CD, bass was arbitrarily rolled off to reduce the cost of making records and increase the capacity of a typical LP (low bass = wide grooves = reduced LP play time, loud bass = deep grooves = thicker records = increased manufacturing cost). It wasn't COMPLETELY universal (as rap/dance 12" singles showed), but for all intents and purposes, it was just the way mainstream records were mastered. As a result, mainstream home audio systems couldn't handle bass, either (remember the sudden appearance of subs and satellite systems almost overnight circa the mid-80s?) Because they couldn't handle bass, and to reduce mastering costs, cassette tapes had the same eq curve applied, and were bass-free as well.
I still remember the favorite album of my childhood -- the Star Wars Christmas Album ("Christmas in the Stars", which, ironically, had Jon Bon Jovi (still a teenager) as its lead singer). At the time, I had no idea why it sounded so incredibly good with headphones on my Dad's stereo, but it did. Unlike the rest of my records, it almost felt like you could reach out and touch the music. It was a feeling I never experienced again until almost a decade later, when CDs were a few years old, and DDD mastering became the high-end norm. For Christmas in 1999, my parents bought me a copy of the newly-(re-)released "Christmas in the Stars" CD (my original record was destroyed by Hurricane Andrew... or more precisely, my parents' disinterest in trying to salvage what to them was just an old record that got wet and moldy along with everything else in the living room). Anyway, it was from reading the cover notes that I finally realized *why* the original album sounded so incredibly great: it was digitally-mastered almost a *decade* before most professionals had even *heard* of "digital mastering".
You'd be surprised how much horsepower you need. ESPECIALLY if the phone is running WinCE/Windows Mobile... and almost certainly, if it's running a de-facto proprietary Linux knockoff ("de-facto proprietary" == the GPL says they have to release the source... but they don't, and nobody in the GPL world has the money or clout to force them).
As a practical matter, the current crop of PDA phones are basically cellular Winmodems that use the CPU for nearly everything. That's why a vintage Palm phone like the Samsung SPH-i500, with creaky 50-60MHz 680x0-derived Dragonball feels about as fast as a WM5 phone with 200+MHz Xscale or OMAP processor... PalmOS has the Dragonball all to itself, because the phone is a completely separate module connected to the Dragonball by little more than a pair of UARTS. The Xscale or OMAP in the WM5 phone, in contrast, has most of its CPU time soaked up by code pretending to be a real DSP. And the bastards are actually trying to cost-reduce them down to SINGLE-CORE cpus for the next crop of phones. Sigh... 500MHz phones slower than a Palm IIIc, here we come...:-(
Take two cars: one has an internal combustion engine and gets 25mpg, the other has a generator used to power electric traction motors. Give both a gallon of gas, and tell them to drive north on the freeway. At normal highway speeds, the car with the internal combustion engine will go about twice as far before it runs out of gas. The ONLY advantage electric cars have is when operating in slow stop & go traffic, because they don't draw (much) power when stopped (well, besides the 3-5 kilowatts needed to power the air conditioner...). That's why hybrids combine a battery-powered electric traction motor with conventional internal combustion engine -- each has a specific advantage in different traffic conditions.
By the same token, someone who lives in Outer Suburbia and commutes 40 miles daily to an office park elsewhere in Outer Suburbia, mostly along a wide freeway with little congestion, won't see much savings at the gas station if he buys a Prius, because the majority of his daily commute will be under conditions where gas engines operate with high efficiency anyway. On the other hand, someone who lives in central Dade County (Miami) and spends an hour driving 6 miles to work through gridlock that's worse than Manhattan, will probably see a big improvement. However, someone driving an electric car powered by a gas/diesel generator would be bankrupted in EITHER scenario, because he'd be subject to the worst of all possible worlds -- low efficiency everywhere along its performance curve.
(by the way, I don't use the "worse than Manhattan" example lightly... every time I've been to Manhattan, the thing that's blown me away more than anything was how WELL the traffic in Manhattan proper seems to flow, compared to Miami. I've been told that's fairly typical... entering and leaving Manhattan is slow, but driving around once you're actually there is apparently pretty easy).
Yep. It's sad, and the designers should be taken out and shot, but there are STILL new TVs costing more than $2,500 that don't have discrete remote codes for things like "on" and "off", or to select a specific source. Like my own TV (Samsung 65" HDTV, ~3 years old). There's no command you can send it that specifically means, "Select s-video #3". Everything is relative. The problem is, they cleverly remove elements that don't have active sources at the moment. That's nice, if you're manually pressing the "source" button on the remote and watching the screen, but makes it almost impossible to program reliable macros on a high-end remote (because the relative position of things change, depending on whether my Gamecube is turned on, or a DVD player is on, or a camcorder is connected to the side). My old TV was almost as bad (I had to send the TV a "channel-up" to force-select the tuner, then toggle "select" the right number of times), but at least I knew that sending a specific sequence would select a specific source.
Sorry. I couldn't help it. As much as I love to bitch about Sprint for not supporting R-UIM cards and/or allowing cool imported CDMA phones from Korea and China to be used, I just couldn't stand by and see Sprint be slandered so brutally. Call them nazis for refusing to activate non-Sprint phones, but for god's sake don't accuse them of something as gruesome and awful as TDMA;-)
Things get even more tangled in Florida, thanks to the way property taxes are assessed. Somebody might have bought a house in 2000 for $180,000 that today has a market value of $460,000, but a taxable value of $220,000 because the taxable value isn't allowed to appreciate faster than the rate of inflation, regardless of what happens to the real estate market as a whole. It's great if you've owned the same house for years, but it sucks if you ever want to move, because it basically means that someone who sells that house for $460,000, then buys a new & smaller house or condo for the same amount of money, would see their annual property taxes more than double because their NEW tax rate would be based on the purchase price of the new home -- $460k vs $220k. At the moment, at least, you can't take your old homestead exemption tax assessment cap with you if you move.
So... let's pretend that our normal Dade County family with house valued at $460k and taxable value of $220k finds itself unfortunate enough to be in the way of a planned freeway widening. Even if the family were offered $500k for their house, and another $50k to compensate them for the cost and annoyance of having to move, they could legitimately argue that the seemingly generous offer STILL wouldn't make them whole, because if they bought a comparable home a block away, their property taxes would STILL go up by at least $5k/year in perpetuity (more or less).
So... under current property tax laws, there really IS no objectively fair compensation that can be calculated as a one-time lump-sum payment that's guaranteed to be fair to BOTH the homeowner and government. If the government paid an amount that included an extra $100k to compensate them for 20 years of taxes $5,000 higher than they'd otherwise be, then the Florida Legislature rolled back everyone's taxes to (potentially hpothetical) pre-2002 levels, the family would make out like bandits and enjoy a huge windfall. On the other hand, if the law never changed, the family would neither make nor lose money for the next 20-30 years, but would eventually run out of surplus funds and WOULD start to lose money every year thereafter. Frankly, the fact that the legislature hasn't gotten its act together long enough to AT LEAST grant portability to eminent-domain sales is inexcusable.
> Endian differences were irritating many years ago, but with the number-crunching power of today, > such differences can be automatically detected and converted.
Trust me on this: they continue to be highly irritating to quite a few people TODAY as well. Yes, chips exist to automagically detect and convert between big and little endian streams... chips that end up not being used in most microcontroller-based circuits because they add to the component cost, so the onus of endian-conversion gets dumped back into the lap of the poor soul writing the firmware, just like it always has.
>Alternative methods to accomplish the same goal have been used as patent work-arounds from the earliest days
And, sadly, that's the reason why little-endian binary will probably be around to haunt us forever. Little-endian binary was a hack to get around somebody else's patent on big-endian binary. The supreme irony is that IBM itself might have even OWNED the original patent, and set into motion decades earlier the chain of events that caused the chosen supplier of CPUs for the IBM PC (Intel) to have gone down the little-endian route instead of the big-endian route when developing the 8086's ancestors.
It's sad, but IMHO everyone is so busy shooting at the wrong demon that we're ignoring the REAL monster: monopoly access to last-mile infrastructure.
Everyone's favorite example of why we need net neutrality is "we have two real choices for internet access: cable and DSL, both of which are run by big greedy companies that want to create walled gardens and extort sites like Google into paying for access". The thing is, that situation only exists BECAUSE in many parts of the country, you can choose between cable and DSL, but can't choose the company that's actually sitting at the other end of your local loop and providing your access to the internet itself. If cable and DSL were forced to sell local-loop access under open, content-neutral pricing and forced to decouple TV and local phone service from access to the cable/line itself (so you could have DSL without phone service, and/or cable internet without TV), our problems would largely be solved. OK, maybe not the problems faced by people who still don't quite understand the difference between "AOL" and "The Internet", or who think the internet begins and ends at Internet Explorer, but at least the problems of the reasonably-urban Slashdot technorati elite (because as a group, we WILL pay $20/month more to use an ISP whose upstream access is provided by multiple companies with promiscuous private peering of their own).
Force unbundled open access to last-mile infrastructure, and the whole issue of net neutrality becomes moot, and the problem solves itself. There's so much fiber, owned by so many competing parties, sitting in the ground right now that NOBODY could truly create an impenetrable walled garden or strip determined internet users of an escape route as long as small ISPs are guaranteed access to a full-speed connection between their rack at the NAP and the end user (who SHOULD have the ability to prioritize data from other sources if desired, since there are plenty of situations where it would be useful and desirable for end users... as long as THEY, not the last-mile provider, can set the priorities).
> That was one of the main things that pushed me towards getting a Palm rather than a WinCE device.... and it's what finally pushed me to get a Sprint PPC-6700 (HTC Apache) to replace my beloved, but quite aged, Samsung SPH-i500. Unlike the current (nasty) crop of Treos, its Graffiti-lookalike works quite nicely. I hate thumbboards, and Handspring's decision to do away with even the courtesy of a soft graffiti area on a 480x320 screen was unforgivable IMHO. Of course, I bought a copy of StyleTap (Palm emulator), and still have fantasies that AccessLinux might offer a $99 SDK that allows a Sprint or Verizon 6700 to be reflashed (sailing in under the corporate radar and reseeding the Palm ecosystem by quickly putting ALP devices directly into the hands & pockets of America's largest bloc of developers and power users without having to screw around with Sprint/Verizon politics and stupid exclusivity deals for months first... all Sprint's computer knows is that the ESN is in its database; it has NO IDEA what OS is actually running on the hardware:-)
Of course, if there's a god, someday the FCC will beat Sprint & Verizon into submission and force R-UIM cards on them. But I'm sure Sprint (at least) would still try some stupid stunt, like implementing R-UIM cards, but still refusing to talk to any phone whose ESN isn't in its magic database regardless of whether there's a Sprint R-UIM card in it:-(
You missed one... you can author a HD-DVD that's less than 5 or 9 gigs, burn it to single or dual-layer recordable red-laser DVD media, and play it back on a HD-DVD player. Sony doesn't allow Blu-Ray format to be burned or played from anything besides genuine Blu-Ray Media. For someone with a prosumer HD camcorder who wants to burn discs (or, say, a college film major), this is a Very Big Deal.
Of course, the ultimate irony would have been for it to have lead even people who'd normally not care about ripping DVDs to go out learn how to rip & decrypt the Sony DVDs so they could re-burn them to work on their own players. And for a half-dozen new ARccOS-ripping apps to appear as a direct result.
There's nothing like buying an expensive disc that HAS to be cracked/ripped to run on your system to make you swear to god you'll just pirate it outright next time and spare yourself the grief of having to crack/rip it yourself from the original...
1. Take native, pristine 1080p60 content. Rip out just the odd frames, then use them to encode a pseudo-1080i60 MPEG-2 stream that sends odd and even fields of sequential odd frames.
2. Now, for each even frame, parse through the generated pseudo-1080i60 stream to fetch the two adjacent fields (comprising a complete progressive frame) surrounding each even frame in the source. Pretend the frames extracted from the pseudo-1080i60 stream are progressive I frames (and fixed as such while encoding), and apply multipass VC-1 and/or MPEG-4 compression techniques to the even frames.
3. Go through the pseudo-VC1/MPEG-4 stream, and replace the odd frames (written and fixed as I frames) with placeholders.
4. Multiplex the now-hacked pseudo-VC1/MPEG-4 stream into the original pseudo-1080i60 stream, physically splitting it on the placeholder boundaries and omitting the placeholders entirely.
To decompress...
1. Parse through until the nearest I frame to the desired starting point is found. Decode the field, and buffer it as the odd scanlines of "frame 1". Decode the following field, and buffer it as the even scanlines of "frame 1". We now have our first frame.
2. temporarily buffer the data from the "e" stream, and grab the next chunk of data from the main MPEG-2 pseudo-1080i60 stream. If it's an I or P frame, decode it and buffer its two fields as the odd and even scanlines of "frame 3". If it's a B frame, keep decoding until enough info is available to finally decode it.
3. Now, go parse through the buffered "e" stream data and re-create the imaginary MPEG-4/VC-1 stream with that data, surrounded by progressive I frames built from frame 1 and frame 3. Decode it as frame 2.
4. continue the pattern... decode MPEG-2, buffer, treat decoded MPEG-2 as progressive I-frames surrounding even frames compressed via more advanced codec, decode, wait for time, update the display to the next frame, rotate the buffers, and continue.
I think something like this is entirely feasible. The fact is, MPEG-2 is horribly inefficient compared to more modern codecs. B/P-heavy multipass offline encoding can recover a fairly big chunk of space compared to traditional realtime MPEG-2 encoding. Treating the decoded MPEG-2 as I frames surrounding the even frames encoded with an even more efficient scheme should easily enable 1080p60 transmission in a way that's backwards-compatible with legacy sets that can only handle 1080i60 streams. Regardless of how much cost the huge ram buffer needed to decode massive chains of B & P frames as well as forward-encoded VC-1 and/or MPEG-4 data adds to the STB or TV, it's still cheaper than trying to approximate the task with a $20k Faroudja box that tries to pull off the same stunt with non-film-source 1080i60 that they do now with broadcast non-film-source 480i60.
Just try watching UFC on SpikeTV. The diagonal chainlink fence surrounding the Octagon looks worse than clothing with bright red pinstripes on a cheap NTSC TV. For all intents and purposes, it's unwatchable. Fortunately, InHD encodes UFC with a sufficiently-high bitrate to encode the fence properly.
Although the main stream would look like 1080i60 to a naive receiver, it would REALLY be 1080p30, with odd and even fields of only the odd frames of the 1080p60 source used to construct the pseudo-1080i60 stream. By delaying rendering to output for at least four to six complete fields (2-3 complete frames) at the receiving end, and sending both sequential fields from the same frame, we ensure that we always have the complete odd frame that came before and after each reconstructed even frame. Given two complete progressive frames, encoding a third progressive frame that falls between them in the source material is almost trivial, given a healthy amount of ram at the receiving end to buffer a few complete frames and pre-buffer forward-encoded changes sent along with earlier, more stable frames. The hardcore artificial-intelligence analysis and encoding would be done once, with end-user receivers doing little more than aggressive MPEG decompression (as opposed to requiring each end user to personally have the hardware to do realtime analysis and AI to try and synthesize the missing data from true interlaced fields).
The main point is that aggressive offline 2-pass compression would free up more than enough space from the main stream to make room for the new "e" stream, and delaying output long enough to have complete "before" and "after" frames in the buffer to reference for the "middle" frame saves us from even more redundant data transfer. There'd be no real "guessing" or AI involved at the receiving end, because the encoder would tell the decoder EXACTLY how the data it HAS should be combined to synthesize/reconstruct the intermediate frame via the "e" stream.
The big point of contention would be whether it's acceptable to skip the kell-filtering to preserve maximum vertical detail, at the expense of increasing interline twitter when viewed by legacy TVs. The de-facto 30fps framerate of the pseudo-1080i60 is less of an issue, because most/all 1080i60 content broadcast today REALLY is from 1080p30 or 1080p24 source ANYWAY. I'm guessing that broadcasters would initially keep the Kell filtering, but gradually start reducing it as time went by and "1080e60" compatible sets became increasingly common, if not the norm.
IMHO, it would be a fairly straightforward way to extend ATSC to include de-facto 1080p60 without breaking backwards-compatibility with existing sets or increasing bandwidth requirements (at least, for non-live video that can be encoded in advance using offline 2-pass compression). Even content with lots of live elements (like CNN) could benefit... the "live" parts would be sent as conventional 1080i60 (possibly with a placeholder "e" stream to tell the decoder to pre-buffer and delay it, but not to expect any new detail at that moment), and the video clips that get shown over and over would be pre-encoded to 1080e60. Sporting events would probably be a lost cause since they're both live AND include lots of rapid frame-to-frame changes, but 720p60 will do perfectly well for most such events anyway. As 2-pass encoding hardware gets faster and cheaper, it might even become feasible to introduce another 2 or 3 frames of buffer delay and start broadcasting sports like golf in 1080e60, too.
I'd be absolutely SHOCKED if at least one group at Faroudja/Genesis(?) isn't busy working on a way to transform 1080p60 source into a 1080i60 stream that any naive TV can display, with a second stream that tells a future Faroudja deinterlacer chip how to combine the previous 2 and next 2 fields to reconstruct what was supposed to be the current progressive frame (buffering four complete 1920 x 540 fields and delaying output by 1/15 sec along the way). Right now, even the best Faroudja deinterlacers have to make educated guesses about how to reconstruct the missing info from alternate field lines. If the deinterlacer had the benefit of knowing how the previous and next two fields related to the current one, it could do a nearly glitch-free job of transforming 1080i60 into 1080p60 in semi-realtime (delayed at the input end by 1/15 sec for analysis, and delayed at the output end by another 1/15 sec for reconstruction... net result, ~1/7 second delay when switching to new channel before output begins). If the processor were able to do the 1080i60->1080e60 ("e", for "enhanced" added datastream) conversion offline (so it could take its time and intelligently choose to compress a few frames more aggressively to give it more bandwidth for additional meta info or detail for an upcoming frame), "1080e60" video would be almost indistinguishable from the original 1080p60 source (barring synthetic videos intentionally rendered to trick the encoder).
No, I don't know anybody who works for Faroudja or has any financial interest in them. But I GUARANTEE the same idea has occurred to them, and they've been working on it for months, if not years. 1080i60 might consume most ATSC bandwidth available when encoded in realtime using conventional commercial encoders, but anyone who's ever screwed around with TMPGENC to make XVCDs back in the old days knows you can get STUNNING results with massive size reduction as long as realtime on-the-fly compression isn't a requirement.
Even if 1080p60 content doesn't exist natively today, it almost certainly will within 5-10 years. Maybe I'm weird, but I've always regarded an expensive high-end TV as a 10-20 year purchase (spending its first decade in the main TV-watching room, then spending the remainder of its life in either the secondary TV-watching room or the master bedroom). I'm in no particular hurry to replace it with a flat TV, mainly because it's in a big, huge armoire that's still going to be a big, huge armoire with a flat TV instead (you can probably tell I'm single... my married co-workers have informed me that they made the same argument to their wives, and had to buy the new, flat TV to put in the big, huge, now-mostly-empty armoire *anyway*).
Now for a dirty little secret: most DLP light engines claiming to be 1080p60 are really playing fast & loose with the definition, and REALLY use DMD arrays with ~960 x 1080 mirrors. They use each mirror to illuminate TWO adjacent horizontal pixels. In effect, they're interlacing the display horizontally, but doing it at a much faster frequency so it's not as noticeable as 60hz interlacing would be. In fact, it wouldn't surprise me if the NEWEST DLP TVs have reduced the mirror count even more, and use each mirror to render 3, 4 or more pixels.
Also, I read somewhere that quite a few low-cost rear-projection LCD TVs are REALLY using 1280x1024 4:3 LCD panels with anamorphic lenses (downsampling 1920 pixels to 1280, and just shaving 56 lines from the top & bottom of the picture). I'm not sure, but I think it's even legal to advertise a LCD TV as being "1080p60" if its physical resolution is lower than 1920 x 1080 (say, 1440 x 1050) without disclaiming the "true" physical resolution of the panel itself. Would I buy a TV with 1440x1050 panel that's $400 less than one with 1920x1080 panel? Probably... but I'd be LIVID if I bought a 1440x1050 panel advertised as "1080p60", then found out 9 months later what the panel's REAL resolution were.
The main problem lies with CRT-based displays. A CRT-based display can be made multisync fairly easily, but needs different coils for each "band" of scanrates. A TV that natively supports 1080i can get away with using the same coil for 480p, because the ~32KHz-36KHz signal bandwidth is close enough to allow it. 720p requires 45KHz of bandwidth, so there's no dodging the issue: if you want a CRT-based display to natively handle 480p, 720p, and 1080i scanrates, you need at least two coils... one for the 32-36KHz signals, and one for the 45KHz signals.
That adds two problems: cost (which is a big deal to manufacturers, even if we're only talking about a dollar or two on a TV meant to sell for $3,000+ circa 2000) and mode-switching (like multisync monitors do when you radically change video modes... a relay thunks, the display briefly goes black, and the new mode settles in). Mode switching is the main reason why CRT-based TVs that natively supported both 720p and 1080i were almost nonexistent (Monivision was the only maker I'm aware of that ever made them). To Joe Sixpack, a TV that goes thunk->black->jiggle->blink when channel surfing is "defective". The IDEAL compromise would have been to make TVs that had two coils, but remained "locked" to the most recently-used coil while channel-surfing until/unless you pressed the "finalize" button on the remote control, then switched to the other coil if appropriate. But to Joe Sixpack, that's too complicated, and to manufacturers, it would have increased costs by a shocking $5-10 per set, so it never happened.
1080p sets are a nearly ideal compromise. 1080i can be directly rasterized (dimming the previous field's scanlines with each new field to simulate CRT fading), and 720p can be trivially rescaled to 1080p in a process that's no different from resizing a picture in Photoshop. Ditto, for 480p and 540p (540p isn't FCC-blessed, but exists in cable, satellite, and other media). In comparison, natively-720p sets brutally mangle 1080i video (usually treating it like 540p60 and averaging each scanline with the one from the previous field/frame to minimize artifacts), and natively-1080i sets mangle 720p60 video even worse (usually, sampling it DOWN to 540 vertical lines from 720, then treating it like 540p60).
At the end of the day, though, we all owe a huge debt of gratitude to Intel and Microsoft (among others), for fighting the TV industry to the bitter end and keeping 480p60 and 720p60 as official modes. If the TV industry had its way, progressive-scan would have never seen the light of day outside of computer monitors, and broadcast TV would have been interlaced forever. It caused lots of confusion and made a bit of a mess during HDTV's first decade, but in the long run, progressive-scan formats WILL win, and we'll all be better off thanks to their availability.
Editing interlaced video was, and (more or less) still is, the nearly-exclusive domain of big networks and large companies (it can be done by low-end equipment, but the results almost always look like shit). In contrast, anyone with a decent laptop, ~$500-2500 worth of software, and even a little bit of experience can do a great job with progressive video. I *guarantee* CNN (and news networks in general) will go the progressive-scan route, if only because it means that a reporter with HD camera, laptop, and EV-DO/UMTS data modem who happens to be in the right place at the right time can shoot, hack, and upload footage while the local affiliates and network guys are still screwing around with the uplink in their van.
Getting back to the original subject, nothing is broadcast in 1080p60 today... but there's absolutely nothing to stop cable and/or satellite providers from doing it 10 years from now. The FCC's official modes apply only to free over-the-air broadcast TV. They have zero say over how the signal sent by cable companies, satellite companies, or output by consumer electronics devices are formatted and streamed -- with the possible exception that cable/satellite boxes MIGHT
Wait until the first Chinese Taikonaut lands on the Moon, or (god forbid) Mars, and plants a big red flag while another one holds and aims the HD video camera that's uplinking via 2 or 3 satellites to every major TV network on Earth. I guarantee you'll see a resurgence of American nationalism-driven space exploration on a scale that hasn't existed since the 1960s.
All kidding aside, I hope the Chinese openly claim ownership of a chunk or two of the moon and/or Mars while they're at it (say, a hundred square kilometer area with permanently-occupied fort somewhere within it, preferably near a corner to facilitate trade and travel among the inhabitants of adjacent forts). If they manage to bring Washington on board (say, by retroactively recognizing US claims to its moon landing sites as long as they're permanently-occupied by the US within a decade) and sweeten the pot a bit by offering adjacent squares to the EU, Russia, and others on similar terms ("it's yours if you want it, but you've gotta land there and inhabit it within a decade... and if you don't have the rockets, we have a few we'll be happy to sell you... in fact, we have a few models on sale THIS VERY WEEK..."), the next century's space race will be off and running.
Why would China insist on firm ownership, but encourage neighbors? Money. The EU might not be in any position for a moon run on short notice... but it could almost certainly afford to buy the vehicles and hardware from China (and probably save a ton of money over what it would have cost to build locally with European labor). China makes tons of money from the sale, and reduces its own risk by having friendly neighbors near their own settlements (to buy/trade supplies from/with, for one).
IMHO, the US messed up big-time when it failed to claim ownership of a chunk of the moon. I guarantee the Chinese won't make the same mistake.
> The intrepid explorers will then feel an incredible burning sensation in their mouth, throat, and lungs > before dying the quick but allegedly-painful death of CO2 poisoning. The atmosphere of Mars is mostly carbon dioxide.
Oops. Guilty as charged. For some inane reason I thought it was mostly nitrogen.
On the other hand, CO2 is even better, because CO2 can be converted into molecular Oxygen through direct electrolysis. So... the hardware for quick jaunts outside is more complex than it would be under a mostly-nitrogen atmosphere, but longer trips are easier to handle as long as reliable power is available.
They won't be using the new suits on Mars (for any extended period of time, at least), and NASA damn well knows it.
For one thing, Mars has an atmosphere. Not directly breathable, of course... but not toxic either. So there's no need for Mars explorers to carry both oxygen AND "bulk" gas (like nitrogen) to give it volume and pressure. Instead, they can do what airplanes do... pressurize the outside air, warm it up, and inject small amounts of pure oxygen into it.
Likewise, a suit for outdoor use on Mars doesn't have to be pressurized beyond respiratory needs, or even airtight. Think: what would you wear to safely go outside at the South Pole in the middle of winter when it's -100C outside and windy. It needs to be highly insulated, and probably incorporate electric or chemical heat... but doesn't need the sheer bulk of moonsuits and EVA suits. If a Mars suit were torn, you might end up with a nasty case of frostbite, but as long as you were able to hook up to a good power and oxygen source you'd probably make it home with treatable injuries.
I fully expect to see NASA testing suits in Antarctica within a decade, both to get practical user evaluations of prototype designs AND solve a few nasty problems we have TODAY down there (if something goes wrong at the South Pole midwinter that requires outdoor travel, right now it's VERY dangerous to go outside there). Antarctica is nowhere near as cold, but I see lots of potential for spinoff technologies down there (like the iBot vs Segway).
Slashdot Mirror
I'm still amazed that they actually use the same ancient machines to do it. I mean, dear god, even if the hourly fees and hardware cost were completely jacked up to outrageous levels, you could probably hire a consultant to make an Asterisk-based system with multiple layers of hardware redundancy to do the exact same thing (wait for ring, answer, announce the current time & temperature, then hang up) for less than it probably cost to lease and maintain those old machines for one year...
It's funny you mention IBM, because the BellSouth Simon (the first true wireless PDA, sold by BellSouth in 1992) was made by IBM. Its text input system guessed the 6 most likely letters and displayed them on a touchscreen, with another spot in the middle to go to the next 6 guesses if none of them were relevant. It's hard to describe its logic, but after playing with it for about an hour, you actually DID start to figure it out subconsciously and learn how many times you'd have to tap the center spot & which one of the 6 spots would have the letter you need.
>What was chinas next-gen format called now again? I would assume their players will be cheap :)
Reading the tea leaves... I'll call it "DVD+HD". Red-laser players, HD-DVD format, $89 at Wal Mart this Christmas. Not as good as HD-DVD, but an improvement over SD-DVD, and likely to be warmly embraced by porn due to having plenty of space for an hour and a half of 720p60 with 224kbit audio. At worst, they'll handle two hours of 720p24, and might even be able to do 1080p24.
It'll be a stopgap format, but it'll kill Blu-Ray dead. Why? Because HD-DVD players will be able to play DVD+HD just fine, but Blu-Ray won't. Remember, HD-DVD players are perfectly willing to play back a 9-gig disc that's mastered like a "real" HD-DVD. So HD-DVD can spend the next 2-5 years limping along and licking its wounds while "DVD+HD" becomes entrenched, then re-emerge as a premium format once the market for videophile-grade discs grows a bit larger. Since Blu-Ray players can't, by design, play anything besides Blu-Ray discs (specifically, there's no such thing as a 9-gig Blu-Ray disc), it has no "Plan B". Blu-Ray will either succeed 100%, end up as a de-facto second format that everything is compatible with (a-la DVD+R and DVD-R), or fades into obscurity after losing to a guerrilla format like "DVD+HD" with no backup plan.
In America, at least, BPL is a political smokescreen. The REAL goal of power companies is to just hang fiber from the poles they already have. However, if they came out and said, "we want to run fiber everywhere our power lines go," the phone and cable companies would have gone berserk. So they pretended instead that they really intend to do something that would be utterly insane on both engineering and accounting grounds, in the hope that once they get the OK, they can roll it out, start interfering with radio (assuming they can even get the network part to actually work reliably), then when the complaints come rolling in, generously volunteer to ditch the whole thing and run fiber instead.
The most surprising thing I discovered during the mid-90s (before recordable CDs were ubiquitous) was how good metal tape with DBX or Dolby C could sound. The biggest revolution brought about by CDs wasn't at the home side, it was at the production side. Pre-CD, bass was arbitrarily rolled off to reduce the cost of making records and increase the capacity of a typical LP (low bass = wide grooves = reduced LP play time, loud bass = deep grooves = thicker records = increased manufacturing cost). It wasn't COMPLETELY universal (as rap/dance 12" singles showed), but for all intents and purposes, it was just the way mainstream records were mastered. As a result, mainstream home audio systems couldn't handle bass, either (remember the sudden appearance of subs and satellite systems almost overnight circa the mid-80s?) Because they couldn't handle bass, and to reduce mastering costs, cassette tapes had the same eq curve applied, and were bass-free as well.
I still remember the favorite album of my childhood -- the Star Wars Christmas Album ("Christmas in the Stars", which, ironically, had Jon Bon Jovi (still a teenager) as its lead singer). At the time, I had no idea why it sounded so incredibly good with headphones on my Dad's stereo, but it did. Unlike the rest of my records, it almost felt like you could reach out and touch the music. It was a feeling I never experienced again until almost a decade later, when CDs were a few years old, and DDD mastering became the high-end norm. For Christmas in 1999, my parents bought me a copy of the newly-(re-)released "Christmas in the Stars" CD (my original record was destroyed by Hurricane Andrew... or more precisely, my parents' disinterest in trying to salvage what to them was just an old record that got wet and moldy along with everything else in the living room). Anyway, it was from reading the cover notes that I finally realized *why* the original album sounded so incredibly great: it was digitally-mastered almost a *decade* before most professionals had even *heard* of "digital mastering".
You'd be surprised how much horsepower you need. ESPECIALLY if the phone is running WinCE/Windows Mobile... and almost certainly, if it's running a de-facto proprietary Linux knockoff ("de-facto proprietary" == the GPL says they have to release the source... but they don't, and nobody in the GPL world has the money or clout to force them).
:-(
As a practical matter, the current crop of PDA phones are basically cellular Winmodems that use the CPU for nearly everything. That's why a vintage Palm phone like the Samsung SPH-i500, with creaky 50-60MHz 680x0-derived Dragonball feels about as fast as a WM5 phone with 200+MHz Xscale or OMAP processor... PalmOS has the Dragonball all to itself, because the phone is a completely separate module connected to the Dragonball by little more than a pair of UARTS. The Xscale or OMAP in the WM5 phone, in contrast, has most of its CPU time soaked up by code pretending to be a real DSP. And the bastards are actually trying to cost-reduce them down to SINGLE-CORE cpus for the next crop of phones. Sigh... 500MHz phones slower than a Palm IIIc, here we come...
Take two cars: one has an internal combustion engine and gets 25mpg, the other has a generator used to power electric traction motors. Give both a gallon of gas, and tell them to drive north on the freeway. At normal highway speeds, the car with the internal combustion engine will go about twice as far before it runs out of gas. The ONLY advantage electric cars have is when operating in slow stop & go traffic, because they don't draw (much) power when stopped (well, besides the 3-5 kilowatts needed to power the air conditioner...). That's why hybrids combine a battery-powered electric traction motor with conventional internal combustion engine -- each has a specific advantage in different traffic conditions.
By the same token, someone who lives in Outer Suburbia and commutes 40 miles daily to an office park elsewhere in Outer Suburbia, mostly along a wide freeway with little congestion, won't see much savings at the gas station if he buys a Prius, because the majority of his daily commute will be under conditions where gas engines operate with high efficiency anyway. On the other hand, someone who lives in central Dade County (Miami) and spends an hour driving 6 miles to work through gridlock that's worse than Manhattan, will probably see a big improvement. However, someone driving an electric car powered by a gas/diesel generator would be bankrupted in EITHER scenario, because he'd be subject to the worst of all possible worlds -- low efficiency everywhere along its performance curve.
(by the way, I don't use the "worse than Manhattan" example lightly... every time I've been to Manhattan, the thing that's blown me away more than anything was how WELL the traffic in Manhattan proper seems to flow, compared to Miami. I've been told that's fairly typical... entering and leaving Manhattan is slow, but driving around once you're actually there is apparently pretty easy).
Yep. It's sad, and the designers should be taken out and shot, but there are STILL new TVs costing more than $2,500 that don't have discrete remote codes for things like "on" and "off", or to select a specific source. Like my own TV (Samsung 65" HDTV, ~3 years old). There's no command you can send it that specifically means, "Select s-video #3". Everything is relative. The problem is, they cleverly remove elements that don't have active sources at the moment. That's nice, if you're manually pressing the "source" button on the remote and watching the screen, but makes it almost impossible to program reliable macros on a high-end remote (because the relative position of things change, depending on whether my Gamecube is turned on, or a DVD player is on, or a camcorder is connected to the side). My old TV was almost as bad (I had to send the TV a "channel-up" to force-select the tuner, then toggle "select" the right number of times), but at least I knew that sending a specific sequence would select a specific source.
> and Sprint offers TDMA
;-)
Argh! No! No! No! Sprint is CDMA.
(breathes)
Sorry. I couldn't help it. As much as I love to bitch about Sprint for not supporting R-UIM cards and/or allowing cool imported CDMA phones from Korea and China to be used, I just couldn't stand by and see Sprint be slandered so brutally. Call them nazis for refusing to activate non-Sprint phones, but for god's sake don't accuse them of something as gruesome and awful as TDMA
Things get even more tangled in Florida, thanks to the way property taxes are assessed. Somebody might have bought a house in 2000 for $180,000 that today has a market value of $460,000, but a taxable value of $220,000 because the taxable value isn't allowed to appreciate faster than the rate of inflation, regardless of what happens to the real estate market as a whole. It's great if you've owned the same house for years, but it sucks if you ever want to move, because it basically means that someone who sells that house for $460,000, then buys a new & smaller house or condo for the same amount of money, would see their annual property taxes more than double because their NEW tax rate would be based on the purchase price of the new home -- $460k vs $220k. At the moment, at least, you can't take your old homestead exemption tax assessment cap with you if you move.
So... let's pretend that our normal Dade County family with house valued at $460k and taxable value of $220k finds itself unfortunate enough to be in the way of a planned freeway widening. Even if the family were offered $500k for their house, and another $50k to compensate them for the cost and annoyance of having to move, they could legitimately argue that the seemingly generous offer STILL wouldn't make them whole, because if they bought a comparable home a block away, their property taxes would STILL go up by at least $5k/year in perpetuity (more or less).
So... under current property tax laws, there really IS no objectively fair compensation that can be calculated as a one-time lump-sum payment that's guaranteed to be fair to BOTH the homeowner and government. If the government paid an amount that included an extra $100k to compensate them for 20 years of taxes $5,000 higher than they'd otherwise be, then the Florida Legislature rolled back everyone's taxes to (potentially hpothetical) pre-2002 levels, the family would make out like bandits and enjoy a huge windfall. On the other hand, if the law never changed, the family would neither make nor lose money for the next 20-30 years, but would eventually run out of surplus funds and WOULD start to lose money every year thereafter. Frankly, the fact that the legislature hasn't gotten its act together long enough to AT LEAST grant portability to eminent-domain sales is inexcusable.
> Endian differences were irritating many years ago, but with the number-crunching power of today,
> such differences can be automatically detected and converted.
Trust me on this: they continue to be highly irritating to quite a few people TODAY as well. Yes, chips exist to automagically detect and convert between big and little endian streams... chips that end up not being used in most microcontroller-based circuits because they add to the component cost, so the onus of endian-conversion gets dumped back into the lap of the poor soul writing the firmware, just like it always has.
>Alternative methods to accomplish the same goal have been used as patent work-arounds from the earliest days
And, sadly, that's the reason why little-endian binary will probably be around to haunt us forever. Little-endian binary was a hack to get around somebody else's patent on big-endian binary. The supreme irony is that IBM itself might have even OWNED the original patent, and set into motion decades earlier the chain of events that caused the chosen supplier of CPUs for the IBM PC (Intel) to have gone down the little-endian route instead of the big-endian route when developing the 8086's ancestors.
It's sad, but IMHO everyone is so busy shooting at the wrong demon that we're ignoring the REAL monster: monopoly access to last-mile infrastructure.
Everyone's favorite example of why we need net neutrality is "we have two real choices for internet access: cable and DSL, both of which are run by big greedy companies that want to create walled gardens and extort sites like Google into paying for access". The thing is, that situation only exists BECAUSE in many parts of the country, you can choose between cable and DSL, but can't choose the company that's actually sitting at the other end of your local loop and providing your access to the internet itself. If cable and DSL were forced to sell local-loop access under open, content-neutral pricing and forced to decouple TV and local phone service from access to the cable/line itself (so you could have DSL without phone service, and/or cable internet without TV), our problems would largely be solved. OK, maybe not the problems faced by people who still don't quite understand the difference between "AOL" and "The Internet", or who think the internet begins and ends at Internet Explorer, but at least the problems of the reasonably-urban Slashdot technorati elite (because as a group, we WILL pay $20/month more to use an ISP whose upstream access is provided by multiple companies with promiscuous private peering of their own).
Force unbundled open access to last-mile infrastructure, and the whole issue of net neutrality becomes moot, and the problem solves itself. There's so much fiber, owned by so many competing parties, sitting in the ground right now that NOBODY could truly create an impenetrable walled garden or strip determined internet users of an escape route as long as small ISPs are guaranteed access to a full-speed connection between their rack at the NAP and the end user (who SHOULD have the ability to prioritize data from other sources if desired, since there are plenty of situations where it would be useful and desirable for end users... as long as THEY, not the last-mile provider, can set the priorities).
> That was one of the main things that pushed me towards getting a Palm rather than a WinCE device. ... and it's what finally pushed me to get a Sprint PPC-6700 (HTC Apache) to replace my beloved, but quite aged, Samsung SPH-i500. Unlike the current (nasty) crop of Treos, its Graffiti-lookalike works quite nicely. I hate thumbboards, and Handspring's decision to do away with even the courtesy of a soft graffiti area on a 480x320 screen was unforgivable IMHO. Of course, I bought a copy of StyleTap (Palm emulator), and still have fantasies that AccessLinux might offer a $99 SDK that allows a Sprint or Verizon 6700 to be reflashed (sailing in under the corporate radar and reseeding the Palm ecosystem by quickly putting ALP devices directly into the hands & pockets of America's largest bloc of developers and power users without having to screw around with Sprint/Verizon politics and stupid exclusivity deals for months first... all Sprint's computer knows is that the ESN is in its database; it has NO IDEA what OS is actually running on the hardware :-)
:-(
Of course, if there's a god, someday the FCC will beat Sprint & Verizon into submission and force R-UIM cards on them. But I'm sure Sprint (at least) would still try some stupid stunt, like implementing R-UIM cards, but still refusing to talk to any phone whose ESN isn't in its magic database regardless of whether there's a Sprint R-UIM card in it
You missed one... you can author a HD-DVD that's less than 5 or 9 gigs, burn it to single or dual-layer recordable red-laser DVD media, and play it back on a HD-DVD player. Sony doesn't allow Blu-Ray format to be burned or played from anything besides genuine Blu-Ray Media. For someone with a prosumer HD camcorder who wants to burn discs (or, say, a college film major), this is a Very Big Deal.
Of course, the ultimate irony would have been for it to have lead even people who'd normally not care about ripping DVDs to go out learn how to rip & decrypt the Sony DVDs so they could re-burn them to work on their own players. And for a half-dozen new ARccOS-ripping apps to appear as a direct result.
There's nothing like buying an expensive disc that HAS to be cracked/ripped to run on your system to make you swear to god you'll just pirate it outright next time and spare yourself the grief of having to crack/rip it yourself from the original...
OK, here's another way to look at it:
1. Take native, pristine 1080p60 content. Rip out just the odd frames, then use them to encode a pseudo-1080i60 MPEG-2 stream that sends odd and even fields of sequential odd frames.
2. Now, for each even frame, parse through the generated pseudo-1080i60 stream to fetch the two adjacent fields (comprising a complete progressive frame) surrounding each even frame in the source. Pretend the frames extracted from the pseudo-1080i60 stream are progressive I frames (and fixed as such while encoding), and apply multipass VC-1 and/or MPEG-4 compression techniques to the even frames.
3. Go through the pseudo-VC1/MPEG-4 stream, and replace the odd frames (written and fixed as I frames) with placeholders.
4. Multiplex the now-hacked pseudo-VC1/MPEG-4 stream into the original pseudo-1080i60 stream, physically splitting it on the placeholder boundaries and omitting the placeholders entirely.
To decompress...
1. Parse through until the nearest I frame to the desired starting point is found. Decode the field, and buffer it as the odd scanlines of "frame 1". Decode the following field, and buffer it as the even scanlines of "frame 1". We now have our first frame.
2. temporarily buffer the data from the "e" stream, and grab the next chunk of data from the main MPEG-2 pseudo-1080i60 stream. If it's an I or P frame, decode it and buffer its two fields as the odd and even scanlines of "frame 3". If it's a B frame, keep decoding until enough info is available to finally decode it.
3. Now, go parse through the buffered "e" stream data and re-create the imaginary MPEG-4/VC-1 stream with that data, surrounded by progressive I frames built from frame 1 and frame 3. Decode it as frame 2.
4. continue the pattern... decode MPEG-2, buffer, treat decoded MPEG-2 as progressive I-frames surrounding even frames compressed via more advanced codec, decode, wait for time, update the display to the next frame, rotate the buffers, and continue.
I think something like this is entirely feasible. The fact is, MPEG-2 is horribly inefficient compared to more modern codecs. B/P-heavy multipass offline encoding can recover a fairly big chunk of space compared to traditional realtime MPEG-2 encoding. Treating the decoded MPEG-2 as I frames surrounding the even frames encoded with an even more efficient scheme should easily enable 1080p60 transmission in a way that's backwards-compatible with legacy sets that can only handle 1080i60 streams. Regardless of how much cost the huge ram buffer needed to decode massive chains of B & P frames as well as forward-encoded VC-1 and/or MPEG-4 data adds to the STB or TV, it's still cheaper than trying to approximate the task with a $20k Faroudja box that tries to pull off the same stunt with non-film-source 1080i60 that they do now with broadcast non-film-source 480i60.
Just try watching UFC on SpikeTV. The diagonal chainlink fence surrounding the Octagon looks worse than clothing with bright red pinstripes on a cheap NTSC TV. For all intents and purposes, it's unwatchable. Fortunately, InHD encodes UFC with a sufficiently-high bitrate to encode the fence properly.
Oops, I left out a few important details.
Although the main stream would look like 1080i60 to a naive receiver, it would REALLY be 1080p30, with odd and even fields of only the odd frames of the 1080p60 source used to construct the pseudo-1080i60 stream. By delaying rendering to output for at least four to six complete fields (2-3 complete frames) at the receiving end, and sending both sequential fields from the same frame, we ensure that we always have the complete odd frame that came before and after each reconstructed even frame. Given two complete progressive frames, encoding a third progressive frame that falls between them in the source material is almost trivial, given a healthy amount of ram at the receiving end to buffer a few complete frames and pre-buffer forward-encoded changes sent along with earlier, more stable frames. The hardcore artificial-intelligence analysis and encoding would be done once, with end-user receivers doing little more than aggressive MPEG decompression (as opposed to requiring each end user to personally have the hardware to do realtime analysis and AI to try and synthesize the missing data from true interlaced fields).
The main point is that aggressive offline 2-pass compression would free up more than enough space from the main stream to make room for the new "e" stream, and delaying output long enough to have complete "before" and "after" frames in the buffer to reference for the "middle" frame saves us from even more redundant data transfer. There'd be no real "guessing" or AI involved at the receiving end, because the encoder would tell the decoder EXACTLY how the data it HAS should be combined to synthesize/reconstruct the intermediate frame via the "e" stream.
The big point of contention would be whether it's acceptable to skip the kell-filtering to preserve maximum vertical detail, at the expense of increasing interline twitter when viewed by legacy TVs. The de-facto 30fps framerate of the pseudo-1080i60 is less of an issue, because most/all 1080i60 content broadcast today REALLY is from 1080p30 or 1080p24 source ANYWAY. I'm guessing that broadcasters would initially keep the Kell filtering, but gradually start reducing it as time went by and "1080e60" compatible sets became increasingly common, if not the norm.
IMHO, it would be a fairly straightforward way to extend ATSC to include de-facto 1080p60 without breaking backwards-compatibility with existing sets or increasing bandwidth requirements (at least, for non-live video that can be encoded in advance using offline 2-pass compression). Even content with lots of live elements (like CNN) could benefit... the "live" parts would be sent as conventional 1080i60 (possibly with a placeholder "e" stream to tell the decoder to pre-buffer and delay it, but not to expect any new detail at that moment), and the video clips that get shown over and over would be pre-encoded to 1080e60. Sporting events would probably be a lost cause since they're both live AND include lots of rapid frame-to-frame changes, but 720p60 will do perfectly well for most such events anyway. As 2-pass encoding hardware gets faster and cheaper, it might even become feasible to introduce another 2 or 3 frames of buffer delay and start broadcasting sports like golf in 1080e60, too.
I'd be absolutely SHOCKED if at least one group at Faroudja/Genesis(?) isn't busy working on a way to transform 1080p60 source into a 1080i60 stream that any naive TV can display, with a second stream that tells a future Faroudja deinterlacer chip how to combine the previous 2 and next 2 fields to reconstruct what was supposed to be the current progressive frame (buffering four complete 1920 x 540 fields and delaying output by 1/15 sec along the way). Right now, even the best Faroudja deinterlacers have to make educated guesses about how to reconstruct the missing info from alternate field lines. If the deinterlacer had the benefit of knowing how the previous and next two fields related to the current one, it could do a nearly glitch-free job of transforming 1080i60 into 1080p60 in semi-realtime (delayed at the input end by 1/15 sec for analysis, and delayed at the output end by another 1/15 sec for reconstruction... net result, ~1/7 second delay when switching to new channel before output begins). If the processor were able to do the 1080i60->1080e60 ("e", for "enhanced" added datastream) conversion offline (so it could take its time and intelligently choose to compress a few frames more aggressively to give it more bandwidth for additional meta info or detail for an upcoming frame), "1080e60" video would be almost indistinguishable from the original 1080p60 source (barring synthetic videos intentionally rendered to trick the encoder).
No, I don't know anybody who works for Faroudja or has any financial interest in them. But I GUARANTEE the same idea has occurred to them, and they've been working on it for months, if not years. 1080i60 might consume most ATSC bandwidth available when encoded in realtime using conventional commercial encoders, but anyone who's ever screwed around with TMPGENC to make XVCDs back in the old days knows you can get STUNNING results with massive size reduction as long as realtime on-the-fly compression isn't a requirement.
Even if 1080p60 content doesn't exist natively today, it almost certainly will within 5-10 years. Maybe I'm weird, but I've always regarded an expensive high-end TV as a 10-20 year purchase (spending its first decade in the main TV-watching room, then spending the remainder of its life in either the secondary TV-watching room or the master bedroom). I'm in no particular hurry to replace it with a flat TV, mainly because it's in a big, huge armoire that's still going to be a big, huge armoire with a flat TV instead (you can probably tell I'm single... my married co-workers have informed me that they made the same argument to their wives, and had to buy the new, flat TV to put in the big, huge, now-mostly-empty armoire *anyway*).
Now for a dirty little secret: most DLP light engines claiming to be 1080p60 are really playing fast & loose with the definition, and REALLY use DMD arrays with ~960 x 1080 mirrors. They use each mirror to illuminate TWO adjacent horizontal pixels. In effect, they're interlacing the display horizontally, but doing it at a much faster frequency so it's not as noticeable as 60hz interlacing would be. In fact, it wouldn't surprise me if the NEWEST DLP TVs have reduced the mirror count even more, and use each mirror to render 3, 4 or more pixels.
Also, I read somewhere that quite a few low-cost rear-projection LCD TVs are REALLY using 1280x1024 4:3 LCD panels with anamorphic lenses (downsampling 1920 pixels to 1280, and just shaving 56 lines from the top & bottom of the picture). I'm not sure, but I think it's even legal to advertise a LCD TV as being "1080p60" if its physical resolution is lower than 1920 x 1080 (say, 1440 x 1050) without disclaiming the "true" physical resolution of the panel itself. Would I buy a TV with 1440x1050 panel that's $400 less than one with 1920x1080 panel? Probably... but I'd be LIVID if I bought a 1440x1050 panel advertised as "1080p60", then found out 9 months later what the panel's REAL resolution were.
The main problem lies with CRT-based displays. A CRT-based display can be made multisync fairly easily, but needs different coils for each "band" of scanrates. A TV that natively supports 1080i can get away with using the same coil for 480p, because the ~32KHz-36KHz signal bandwidth is close enough to allow it. 720p requires 45KHz of bandwidth, so there's no dodging the issue: if you want a CRT-based display to natively handle 480p, 720p, and 1080i scanrates, you need at least two coils... one for the 32-36KHz signals, and one for the 45KHz signals.
That adds two problems: cost (which is a big deal to manufacturers, even if we're only talking about a dollar or two on a TV meant to sell for $3,000+ circa 2000) and mode-switching (like multisync monitors do when you radically change video modes... a relay thunks, the display briefly goes black, and the new mode settles in). Mode switching is the main reason why CRT-based TVs that natively supported both 720p and 1080i were almost nonexistent (Monivision was the only maker I'm aware of that ever made them). To Joe Sixpack, a TV that goes thunk->black->jiggle->blink when channel surfing is "defective". The IDEAL compromise would have been to make TVs that had two coils, but remained "locked" to the most recently-used coil while channel-surfing until/unless you pressed the "finalize" button on the remote control, then switched to the other coil if appropriate. But to Joe Sixpack, that's too complicated, and to manufacturers, it would have increased costs by a shocking $5-10 per set, so it never happened.
1080p sets are a nearly ideal compromise. 1080i can be directly rasterized (dimming the previous field's scanlines with each new field to simulate CRT fading), and 720p can be trivially rescaled to 1080p in a process that's no different from resizing a picture in Photoshop. Ditto, for 480p and 540p (540p isn't FCC-blessed, but exists in cable, satellite, and other media). In comparison, natively-720p sets brutally mangle 1080i video (usually treating it like 540p60 and averaging each scanline with the one from the previous field/frame to minimize artifacts), and natively-1080i sets mangle 720p60 video even worse (usually, sampling it DOWN to 540 vertical lines from 720, then treating it like 540p60).
At the end of the day, though, we all owe a huge debt of gratitude to Intel and Microsoft (among others), for fighting the TV industry to the bitter end and keeping 480p60 and 720p60 as official modes. If the TV industry had its way, progressive-scan would have never seen the light of day outside of computer monitors, and broadcast TV would have been interlaced forever. It caused lots of confusion and made a bit of a mess during HDTV's first decade, but in the long run, progressive-scan formats WILL win, and we'll all be better off thanks to their availability.
Editing interlaced video was, and (more or less) still is, the nearly-exclusive domain of big networks and large companies (it can be done by low-end equipment, but the results almost always look like shit). In contrast, anyone with a decent laptop, ~$500-2500 worth of software, and even a little bit of experience can do a great job with progressive video. I *guarantee* CNN (and news networks in general) will go the progressive-scan route, if only because it means that a reporter with HD camera, laptop, and EV-DO/UMTS data modem who happens to be in the right place at the right time can shoot, hack, and upload footage while the local affiliates and network guys are still screwing around with the uplink in their van.
Getting back to the original subject, nothing is broadcast in 1080p60 today... but there's absolutely nothing to stop cable and/or satellite providers from doing it 10 years from now. The FCC's official modes apply only to free over-the-air broadcast TV. They have zero say over how the signal sent by cable companies, satellite companies, or output by consumer electronics devices are formatted and streamed -- with the possible exception that cable/satellite boxes MIGHT
Wait until the first Chinese Taikonaut lands on the Moon, or (god forbid) Mars, and plants a big red flag while another one holds and aims the HD video camera that's uplinking via 2 or 3 satellites to every major TV network on Earth. I guarantee you'll see a resurgence of American nationalism-driven space exploration on a scale that hasn't existed since the 1960s.
All kidding aside, I hope the Chinese openly claim ownership of a chunk or two of the moon and/or Mars while they're at it (say, a hundred square kilometer area with permanently-occupied fort somewhere within it, preferably near a corner to facilitate trade and travel among the inhabitants of adjacent forts). If they manage to bring Washington on board (say, by retroactively recognizing US claims to its moon landing sites as long as they're permanently-occupied by the US within a decade) and sweeten the pot a bit by offering adjacent squares to the EU, Russia, and others on similar terms ("it's yours if you want it, but you've gotta land there and inhabit it within a decade... and if you don't have the rockets, we have a few we'll be happy to sell you... in fact, we have a few models on sale THIS VERY WEEK..."), the next century's space race will be off and running.
Why would China insist on firm ownership, but encourage neighbors? Money. The EU might not be in any position for a moon run on short notice... but it could almost certainly afford to buy the vehicles and hardware from China (and probably save a ton of money over what it would have cost to build locally with European labor). China makes tons of money from the sale, and reduces its own risk by having friendly neighbors near their own settlements (to buy/trade supplies from/with, for one).
IMHO, the US messed up big-time when it failed to claim ownership of a chunk of the moon. I guarantee the Chinese won't make the same mistake.
> The intrepid explorers will then feel an incredible burning sensation in their mouth, throat, and lungs
> before dying the quick but allegedly-painful death of CO2 poisoning. The atmosphere of Mars is mostly carbon dioxide.
Oops. Guilty as charged. For some inane reason I thought it was mostly nitrogen.
On the other hand, CO2 is even better, because CO2 can be converted into molecular Oxygen through direct electrolysis. So... the hardware for quick jaunts outside is more complex than it would be under a mostly-nitrogen atmosphere, but longer trips are easier to handle as long as reliable power is available.
They won't be using the new suits on Mars (for any extended period of time, at least), and NASA damn well knows it.
For one thing, Mars has an atmosphere. Not directly breathable, of course... but not toxic either. So there's no need for Mars explorers to carry both oxygen AND "bulk" gas (like nitrogen) to give it volume and pressure. Instead, they can do what airplanes do... pressurize the outside air, warm it up, and inject small amounts of pure oxygen into it.
Likewise, a suit for outdoor use on Mars doesn't have to be pressurized beyond respiratory needs, or even airtight. Think: what would you wear to safely go outside at the South Pole in the middle of winter when it's -100C outside and windy. It needs to be highly insulated, and probably incorporate electric or chemical heat... but doesn't need the sheer bulk of moonsuits and EVA suits. If a Mars suit were torn, you might end up with a nasty case of frostbite, but as long as you were able to hook up to a good power and oxygen source you'd probably make it home with treatable injuries.
I fully expect to see NASA testing suits in Antarctica within a decade, both to get practical user evaluations of prototype designs AND solve a few nasty problems we have TODAY down there (if something goes wrong at the South Pole midwinter that requires outdoor travel, right now it's VERY dangerous to go outside there). Antarctica is nowhere near as cold, but I see lots of potential for spinoff technologies down there (like the iBot vs Segway).