Comparing a GPU, an SIMD (single instruction, multiple data) vector processor, to a CPU, a superscalar sequential processor, is like comparing apples and oranges.
To be fair, modern superscalar CPUs, particularly x86 (or x86-64), have extensively optimized SIMD units, in addition to their sequential/general purpose operations. The very reason Core2 outperformed its Opteron counterparts is because of much better SIMD performance. That generally means SSE instructions, but there are other options as well. And you can be absolutely sure x264 heavily utilizes those SSE instructions, in addition to every other feature of the CPU it can.
Having both of these types of processors in the same machine is asking for trouble. They require two incompatible programming models.
Integrating SIMD instructions into CPUs seems to have gone off without a hitch, and no world-ending upheavals. Similar, while it would be a mess to program specifically for an ASIC/GPU, it wouldn't be at all difficult to just have a few "multimedia" instructions in your code, and have the compiler opt to route them to the CPU for processing. ie. you're still programming for the CPU, and only using the GPU as if it's an independent CPU subsystem, much like an x87/FPU.
To begin with, x264 blows the water out of Badaboom in terms of speed when similar settings are used.
If you'd RTFA, you'd see this disparity is repeatedly mentioned, and they attempted to make a fair comparison.
In a direct comparison, using as close to the same visual quality settings as we could, Handbrake's circa February 2008 X264 codec actually beat the Elemental encoder by almost a minute. Image quality was roughly the same; we've included several stills below so you can directly compare the results.
H.264/AVC includes lossless compression as well as lossy. The same is true for the wavelet based "snow" codec. Still, I'd recommend FFV1 for best compression, as long as you don't need the video to be playable by all the standard H.264 decoders out there.
if you want lossless, use HuffYUV, Lagarith, or FFV1 (or one of a countless variety of similar proprietary formats, such as Sheer YUV). Of course, this will give far larger file sizes, for obvious reasons.
This test is about reencoding from a DVD to H.264/AVC. If you want lossless quality, you need only copy the MPEG-2 stream... Reencoding to a lossless format will dramatically increase the file size, without any quality improvement.
Wouldn't archival-quality backups be actual MPEG instead of H.2 or whatever?
You may have a point, or you might not. Depends on the definition of "archival", and your specific purpose for doing so. I imagine most historians who deal with digital data would scoff at your conflating the terms used to describe their work, with some home user who just wants to back-up their DVDs...
There's certainly going to be loss, when encoding from MPEG-2 DVDs to H.264. But considering how ridiculously large DVD video is for the relatively small amount of data it contains, I'd say a tiny drop in quality is generally acceptable in exchange for reducing the storage space required for near-as-high-quality backups of your DVDs in (eg.) 1/10th the space.
Don't quote me on that, though, it's just a hypothetical example. I just recently finished explaining, here, why H.264 isn't all that much more effective than MPEG-2 where indistinguishable/high-quality (rather than just "watchable") is desired: http://slashdot.org/comments.pl?sid=956141&cid=24940379 In fact, you could probably re-compress a DVD with MPEG-2 (instead of H.264) and get equivalent quality at almost equally low data-rates, simply because the DVD producer's MPEG-2 encoders are terrible, and the settings they use (GOP size, fixed resolution/black borders, high frequency noise, etc.) waste a LOT of the bitrate on things which really don't improve visual quality.
And to be a bit pedantic... H.264 is, in fact "MPEG". It's MPEG-4 AVC (Part10), while DVDs use MPEG-2.
This is the most obvious and boring insight they could possibly offer... Everyone with the slightest interest knows this already.
The low quality of hardware-based video encoder cards is a very well-known fact, and those MPEG encoders cards are just ASICs on a PCI card, almost exactly the same hardware as your video card.
The point of offering up APIs for GPUs, and AMD's attempt to integrate the GPU ASIC with the CPU via HyperTransport, is aimed at improving things, however.
x264 does a good job because it's an open source project, with several skilled and interested individuals continually tweaking the code to improve quality and performance. Once hardware-based video encoding routines aren't hidden in closed-source firmware on a dedicated card, the same development effort can step up and improve HARDWARE encoding now, exactly as they have with software.
Not only can quality be significantly improved, you can expect performance to improve significantly as well, even with greater quality. The initial implementation of any codec is always relatively poor performing, and low quality, so this wouldn't even be an insightful observation if it was comparing x264 with any other software based encoder... The only difference is that a new software h.264/AVC encoder would be SLOWER than x264, as well as being much lower quality.
Wasting $$ on 1 endeavor does not justify wasting $$ on another. I ask sincerely - Can anyone tell me why it makes good long- or short-term financial sense to put human beings on Mars?
It is well-known, in economic theory, that some investments return much more money than is spent, as future economy growth.
You could say we're pissing away money on building so many public roads around the country, but all indicators say for every $1 spent on roads, the economy grows by almost $6.
The same is even more true for high technology. Military spending, developing jet aircraft, is directly responsible for the development of the civilian airline industry, particularly jet aircraft. Did we piss away that money, too? Seems like Boeing, Northrup, Lockheed, GE, Pratt&Whitney, etc., bring in a hell of a lot of money... no doubt many times more than the US Gov spent in the first place.
The Apollo program is in large part directly responsible for much of the economic and technological growth this country has seen since the '60s. This program, as well, could jump start the economy. This project in particular could yield a new nuclear reactor design that could potentially be useful here on earth.
I'm curious as to why being concerned about putting reactor waste on top of a rocket full of highly reactive chemicals makes a person "monumentally STUPID."
First, because NASA rockets have a very high reliability rating. It's going to be very, very rare for one carrying nuclear materials to fail to make orbit.
Second, a small amount of radioactive material being accidentally dispersed, very high in the Earth's atmosphere, would cause it to disperse widely before what's left of it settles down to ground level. Resulting in a minimal increase in the level of natural background radiation. ie. Even if it everything goes wrong, the potential for health effects are minimal, and probably much less significant than something mundane, like having a coal power plant in operation near you.
Third, and primarily, because radioactive material isn't going to just be put in a ziplock bag and dropped on top of a rocket... NASA has a long history of sending up LOTS of radioactive material, but they do so in extremely well-engineered containers. Even sending it to space, where weight is a high premium, the nuclear material casings are extremely robust...
We KNOW it's a extremely robust containment system NASA uses, because there have been several failures, and several of the devices have reentered the atmosphere in the worst possible circumstances, and yet we're not dead. In fact, to the best of my knowledge, despite half a dozen NASA incidents, none of them have resulted in radioactive material being released. It's actually kind of funny... For all the hysteria about radioactive material, Apollo 13's RTG (radioactive thermo-electric generator) is still chugging away on the floor of the Pacific Ocean, not too far off the coast of CA, after falling, uncontrolled, from space.
And finally, because the Russians have been less careful than NASA, and have been dumping radioactive material into our atmosphere for more than 30 years... It happens, and people aren't dropping like flies.
I don't know what part of this you think he's technically right on, other than that he worked for incompetents, which seems to be true.
Well, the fact that they're contracting outside Cisco experts now suggests nobody else there was technically competent enough to manage the network.
The fact that the network stayed up and running without a hitch, while he was in jail and nobody else had access, suggests he did know what he was doing, and refusing to allow anyone to access the routers to make changes seems to work quite well to keep the system working.
The fact that his supervisors are moronic and useless is no small thing, either.
That said, his actions are still beyond reprehensible.
His actions were extremely stupid, but I fail to see why this idiot's relatively non-disruptive actions rise to the level of criminal prosecution.
Russian space technology tend to be simple, inefficient, based on the oldest technology they can get away with, and remains unchanged pretty much as long as they aren't forced to improve it.
Russian tech is really the complete polar opposite of NASA tech, so such exchanges very rarely work out.
Don't you need water to make electricity with a nuclear reactor, and also to cool the core?
The core needs to be cooled, but there is absolutely no reason water inherently needs to be used for that purpose. It just happens to be sufficiently cheap and abundant here on Earth that we use it.
Getting anything into space, and all the way out of earth orbit, is monumentally EXPENSIVE.
Digging a big hole in the ground is monumentally CHEAP (at least in relative terms).
The people you've heard from, that are scared of sending radioactive material into space, are monumentally STUPID.
Also, fissile nuclear material is a highly valuable, relatively scarce, and non-renewable resource. It's more than likely that we'll need to dig that stuff up again in a century, and reprocess it. Quite a bit harder to do so if it's on it's way to Pluto.
Scientists say an understanding of how the Twin Towers collapsed will help them develop the materials needed to build fusion reactors.
Steel is used so widely, in large part, because it's cheap... Iron is one of the most abundant elements on the planet. Many other materials exist that are stronger than steel, lighter than steel, handle MUCH higher temperatures, etc., etc.
For a fusion reactor, however, "cheap" isn't going to be all that important... More exotic materials that can better handle high temperatures would be easily within reach when you're able to generate that much power.
The article completely fails to explain why we, for some reason, MUST use some (not-yet invented) form of "steel" for the walls of fusion reactors. Boron Carbide, Tungsten, titanium, etc., sound like much better options for this application. While this article sounds like a flimsy excuse to exploit this anniversary.
I assumed that you were making a point that VP7 may be theoretically better, whilst being impractical at present.
VP7 is a very good codec (and has been around for a while now), but gets completely ignored, because it's proprietary. Not that On2 wouldn't be happy to do the RAND thing, as well as hand out the source code of VP7 to any company out there willing to pay a small amount of money for it... After all, VP3.2 is open source (Theora) and VP6 is part of Flash v8. And in the past they've often committed to keeping license fees much lower than modern MPEG standards.
But, not being a standard, means economies of scale don't kick in... When you're making a VP7 decoder chip, which is only going to be used in a few million boxes for DVB2 (versus innumerable millions of boxes that are likely to use H.264 at one time or another) the cost of designing the chip, and setting up the plant to produce them, keeps prices quite a bit higher. Hence the rationale for standards.
Still, that's just ONE aspect to keep in mind when selecting the video codec you want to use in your standard, for the next several years. Things like license fees, or performance, may negate that added expense.
My only point being... it's very tricky to chose the ideal codec for any standard. You can't just pick something recent and assume it will be the best option into the future. And planning too much for the "future" may drive up prices and ensure that your standard doesn't get adopted, in the present, and instead dies a slow death on the shelf.
The general level of knowledge in "geek fields" on Slashdot is - outside of a few areas (e.g. general programming, MMORPGs, etc) - not as high as most people here would like to think.
Yes, that's certainly true. However, I would point out that there are actually a pretty good number (albeit a very small percentage of the readership) of experts in just about any field that frequent/. It seems they only poke their heads out on rare occasions, however. This leads to strange phenomenon like an article on (eg.) a new RISC CPU getting lots of mindless, worthless, and inaccurate comments... meanwhile, when the same story gets duped two days later, that second article on the subject gets extremely good comments, extensively detailing internals of microprocessors, and similar. Who knows why?
In addition, there are a few regulars who both know what they're talking about, and seem to comment on/. frequently for whatever their reasons. The two that come to mind are Animats and Doc Ruby, (in addition to myself if I may be so bold), who I frequently see offering accurate insights, even though each has their own shortcomings. eg. http://slashdot.org/comments.pl?sid=954211&threshold=2&mode=nested&cid=24883605
I'm unclear which one you're referring to. I normally link stuff like that.
I should have phrased that "that will be reasonably practical by the time it's expected to see mainstream use".
I don't understand. What's not "practical" about VP7?
If they're wrong fine, but I'd rather you pointed out what or why you still disagreed with them rather than disragarding it.
I have yet to ever find ANYONE here on/. with whom I can have a rational discussion about codec internals.
Never the less, the last line of my reply is "See the other reply to my earlier comment for details." which you apparently didn't do, or you'd have found a bit more detail.
You're also welcome to look-up subjective benchmark comparisons of H.264/AVC and MPEG-2, which, even if they've biased the test to use old and poor quality MPEG-2 encoders, at the very least, will demonstrate the diminishing returns of H.264/AVC at increased bitrates/quality.
And finally, there are inherent limits that audio and video codecs cannot possibly exceed... For audio, that limit is called "Perceptual Entropy" (PE), and was defined decades ago. Once you exceed PE, you no longer have any hope of reproducing an audio signal that cannot be distinguished from the uncompressed original... You can only hope to make it sound acceptable, the distortions non-obvious, and eliminate sounds that might seem like they don't belong, anyhow. MPEG-1 Layer II audio, as used in DAB, is already quite close to that limit, and 128kbps compression substantially exceeds the PE for 44.1KHz stereo audio.
For video, I will admit I have never heard of such a nice simple term and single study to exactly define the limit... Still, I'd be willing to make an educated guess that the figure is no more than 40:1, because (like PE with audio) a rather sharp tailing-off of improvements can be seen in subjective codec tests when nearing that level of compression, which spans the full range of codecs, no matter the technology used.
As with audio, even early lossy video codecs (like MPEG-2) are sufficiently close to that fundamental limit to make the development of better high-bitrate codecs largely pointless. Instead, the focus has been, and continues to be, on the low-end, where you're simply trying to make it look "good", rather than identical, and can flexibly discard perceptual information in a way that it isn't too... distracting.
There is still some room for debate on the subject, since MPEG-2 doesn't entirely hit the perceptual limits of lossy compression. Still, newer codecs don't have very much room to squeeze better compression out of video, while maintaining high-quality video that is close to being indistinguishable from the original.
But if you want to argue that point with me, you face two further problems... First, I've used H.264/AVC encoders and recent/advanced MPEG-2 encoders plenty, so I can speak pretty conclusively when I say there's not much improvement to be had at high bitrates (but like HE-AACv2, it does an impressive job at very low bitrates). Secondly, I know codec internals pretty well, so I can also attest that H.264/AVC is heavily based on the same technologies as it's predecessors (MPEG-1, MPEG-2), and that all the (terribly CPU-hungry) improvements that have been made (eg. qpel vs half-pel, multiple ref/anchor frames, in-loop deblocking, et al.) simply can't provide very much compressibility improvement with high quality (weakly quantized) materials... The amount of change and randomness is too high for such tricks to be effective, so the encoded error remains the most substantial consumer of bits.
I can afford the cost, but I don't know how my SS-dependent parents or Welfare-dependent persons are supposed to be able to afford all these rooftop antenna upgrades.
What "upgrade"?
If you or they had an antenna before, it's pretty likely it will continue to work just fine for digital.
Of course there are situations where people needed just VHF, but that's pretty rare. If they needed just UHF, it's pretty unlikely they will now need VHF as well.
Even if you've got such a situation, and they can only watch half the channels they used to, they're not exactly in dire straights because of it.
Still, progress is never without some pain. That doesn't make it a "boondoggle".
we may as well go for the most efficient, modern one.
So, you're advocating the use of On2's VP7 video codec for DVB2?
A codec always has trade-offs. Making the blanket statement that any one is better than another is simplistic and quite naive.
As I've said repeatedly, even ignoring all else but quality at a given bitrate, H.264/AVC isn't necessarily ANY better than MPEG-2 in this (HDTV) usage case. It's great if you want to broadcast lots of barely legible material using very little bandwidth, but it's not so incredible at high bitrates and high quality.
Problem is that if you're too conservative, you end up with something like the DAB digital radio standard in the UK which, even though it's been hyped as the future of radio, is generally agreed to be based on already-dated technology, with sub-FM sound quality at the compression levels most stations use.
No amount of technological advancement can resolve a political problem...
As far as sound quality, DAB is very good, actually. The MPEG-1 Layer II audio codec does exceptionally well at high bitrates (192kbps or above is easily CD quality). The big (sound quality) problem is, DAB isn't being used as it was designed.
Switching from all analog to all digital would have freed up tons of radio spectrum, allowing for a lot more channels, even at very high quality. The analog didn't get entirely switched off, however, so that extra space didn't arrive. Then, each station having to maintain a digital station, in addition to their analog signal just became a nuisance, hardly worth spending more money on. So, everybody drops down to the barely tolerable quality levels, to squeeze as many channels into the small amount of spectrum available, and to make each as cheap to operate as possible.
Using the most advanced audio codecs won't solve this problem... You just can't get CD-perfect audio at 128kbps. And even if you could, do you want to bet that broadcasters aren't going to pull the same trick again, and lower the bitrate even further, until the sound quality with the newer codecs is less than FM, and barely tolerable, to save some money and squeeze more channels in?
HE-AACv2 has the same benefits and limitations as H.264/AVC. See the other reply to my earlier comment for details.
HE-AAC isn't really an improved codec. It's simply AAC with high-frequency sounds added to it (AAC+ SBR).
You're neglecting to mention parametric stereo (PS).
So, no, you're not going to get a smaller file with HE-AAC, but you are going to get better high-frequency content like cymbals, flutes, et cetera.
This is nonsense. If you got better sound quality at a given bitrate, you simply reduce the bitrate further until you get approximately the original quality level.
Especially at low bitrates. AAC sounds really bad at 16 kbit/s, like listening to music over a phone, but HE-AAC (AAC+SBR) sounds as clear as FM radio thanks to its high-frequency preservation.
SBR isn't about preserving high frequencies AT ALL. In fact it's about eliminating the high frequencies completely, and using the low frequencies to guess/approximate what higher frequency content might sound like.
It's a clever perceptual trick (much like intensity joint-stereo), but like most similar tricks, it only works on low-quality content. Once you start increasing the bitrate to the point where regular (low complexity AAC) compression doesn't do terribly, such tricks start to do... worse, and are best simple disabled.
Anybody who has owned an early-production MPEG2-encoded Bluray versus a MPEG4-encoded HD-DVD, can tell you that's there's less macroblocking with the newer codec.
Anyone that has owned a dog can tell you that they're better than cats...
Anecdotes are useless.
The fact that there are crappy MPEG-2 encoder out there, and good MPEG-4 encoders, DOES NOT imply that MPEG-2 is therefore, bad.
With MPEG-4 AVC/H.264, you should NEVER see macroblocking, because there's a dynamic in-line deblocking filter defined in the spec... Its required.
However, using a deblocking filter (on MPEG-2 videos) may get rid of the blocks, but that doesn't mean the picture is going to be better. You generally trade blockiness for blurriness, and H.264/AVC is no exception...
So, here's a very simple, useful standardized measurement:
The devil is in the details.
1. Capacity of battery in mAh, when new, after 6 months, and after 12 months.
You want WATTS, not just Amps, or else they can just halve the voltage and double the amps, with a trivial change to the battery pack.
Battery capacity over time varies SUBSTANTIALLY based on what level of charge is maintained over that period of time, and how many charge/discharge cycles it goes through. With certain types of batteries, how quickly it is discharged each time, and whether memory effects are mitigated by usage patterns, can make a huge difference as well.
2. Power consumption of machine when doing video playback with screen set to 75% brightness, and all ports and networks enabled ("high").
Video playback power consumption depends HIGHLY on the software being used (Media Player vs. MPC vs. MPlayer-win), the codec required to decode the video in question, and the bitrate and resolution at which the video was encoded.
Port power consumption can be screwed with as well. Even if they're "ON" doesn't mean they can't effectively shut themselves off when there's no traffic.
3. Power consumption of machine when surfing the web, with screen at 50%, and wifi enabled ("medium").
Depends on the web browser software, complexity of the pages being view, etc.
4. Power consumption of machine when doing word processing with screen set to minimum brightness (not off!), and all ports and networks disabled ("low").
Notepad or Office 2007? On Windows 95 or Vista?
Posting a single "hours" figure is obviously rubbish, it does not count for battery decay, nor the wildly different ways we actually use notebooks when we're informed.
An "hours" figure is just as useful as the tests you've described... You're just providing 5 different figures... Average them together, and you've got a single figure again.
An hours figure would still be perfectly useful, if things like advanced power management didn't jump in and screw up the test. Pretty much the same thing as happened with EPA gas mileage figures, and hybrids...
At the very least, a single figure allows you to at least compare usage time from one laptop to another. Even if neither figure is realist, as long as they're both unrealistic in the same way, and to the same degree, they're meaningful when relatively comparing one to another.
Just wondering here, how would a move like this affect marketing of computers?
They'll leave the old 10 HOURS figure, in huge numbers on the packaging. Then have an asterisks, and a tiny footnote that says "TYPICAL BATTERY LIFE: 4 hours".
Properly, we should be told the capacity of the battery and the consumption of the machine at highest and lowest levels.
You still have the same problem. Now you're simply moving the problem from calculating "battery life" to calculating "power consumption", and leaving consumers with an extra bit of math to do...
"Lowest" power consumption is tricky, because you've now got to define what parts of the machine have to be functional in this minimal state. ie. You'd get a huge boost in battery life if you shut off the LCD screen, backlight, and graphics chip.
Maximum isn't exactly easy, either... Does this include external devices drawing their power from the laptop ports? USB, Firewire, speakers, mouse, etc., it's pretty easy to drive the power consumption WAY up, with a few ridiculously power-hungry external devices.
Battery capacity is pretty trivial, and is already notated on nearly every battery I've ever seen.
Though I should make clear that DVB-T is only used for standard res transmissions (*) and has been in proper use here since the late 1990s, so it at least has a good excuse for being based on 1990s tech(!). Even though we're only just *now* starting to switch off analogue in favour of this already dated system!
Although referring to the UK (and explaining why your system isn't as good) you've just described the US DTV switchover precisely...
Digital transmissions (in highdef, no less) in the US have been going on longer than DVB-T transmissions in the UK and most everywhere else in the world. ATSC is also an even OLDER standard than DVB-T by at more than couple years, or perhaps more depending on how you want to look at it.
the UK/European DVB-T boxes won't handle hi-res. So we're getting another new standard for that which probably *will* use the more modern and efficient H.264.
Indeed. You get to waste twice the bandwidth, having one lowdef channel, and one highdef. And everyone needs to buy a second box if they want to get the latter. ATSC isn't sounding so bad after all.
And to be honest, I'd have thought MPEG-2 would be horribly bandwidth-hungry for hi-def and a pointless choice given that more advanced codecs are now available
You'd be wrong. First, because H.264/MPEG-4 AVC simply wasn't available. Secondly, because increased resolution (and/or framerates) brings substantial additional economies with lossy video codecs.
And finally, there's the law of diminishing returns... MPEG-2 is a very good format, and it's very difficult to design something better. H.264/AVC is extremely computationally intensive, and for all that work, you're extremely lucky if you can get twice the compression out of it. In fact, the 2X figure that's commonly cited to explain H.264/AVC's superiority over MPEG-2 really only applies at extremely low bitrates (eg. streaming video), while the two being to converge as bitrate increases...
You can see the same thing with audio... AAC came out at the same time as MPEG-2, and despite more than a decade, there's nothing out there to surpass it. Now, HE-AACv2 is newer, but even those heavily interested in it, openly admit that it's only better at low bitrates, and at 128kbps (for stereo) it provides no improvement over plain AAC (LC-AAC).
Slashdot Mirror
To be fair, modern superscalar CPUs, particularly x86 (or x86-64), have extensively optimized SIMD units, in addition to their sequential/general purpose operations. The very reason Core2 outperformed its Opteron counterparts is because of much better SIMD performance. That generally means SSE instructions, but there are other options as well. And you can be absolutely sure x264 heavily utilizes those SSE instructions, in addition to every other feature of the CPU it can.
Integrating SIMD instructions into CPUs seems to have gone off without a hitch, and no world-ending upheavals. Similar, while it would be a mess to program specifically for an ASIC/GPU, it wouldn't be at all difficult to just have a few "multimedia" instructions in your code, and have the compiler opt to route them to the CPU for processing. ie. you're still programming for the CPU, and only using the GPU as if it's an independent CPU subsystem, much like an x87/FPU.
If you'd RTFA, you'd see this disparity is repeatedly mentioned, and they attempted to make a fair comparison.
In a direct comparison, using as close to the same visual quality settings as we could, Handbrake's circa February 2008 X264 codec actually beat the Elemental encoder by almost a minute. Image quality was roughly the same; we've included several stills below so you can directly compare the results.
H.264/AVC includes lossless compression as well as lossy. The same is true for the wavelet based "snow" codec. Still, I'd recommend FFV1 for best compression, as long as you don't need the video to be playable by all the standard H.264 decoders out there.
This test is about reencoding from a DVD to H.264/AVC. If you want lossless quality, you need only copy the MPEG-2 stream... Reencoding to a lossless format will dramatically increase the file size, without any quality improvement.
You may have a point, or you might not. Depends on the definition of "archival", and your specific purpose for doing so. I imagine most historians who deal with digital data would scoff at your conflating the terms used to describe their work, with some home user who just wants to back-up their DVDs...
There's certainly going to be loss, when encoding from MPEG-2 DVDs to H.264. But considering how ridiculously large DVD video is for the relatively small amount of data it contains, I'd say a tiny drop in quality is generally acceptable in exchange for reducing the storage space required for near-as-high-quality backups of your DVDs in (eg.) 1/10th the space.
Don't quote me on that, though, it's just a hypothetical example. I just recently finished explaining, here, why H.264 isn't all that much more effective than MPEG-2 where indistinguishable/high-quality (rather than just "watchable") is desired: http://slashdot.org/comments.pl?sid=956141&cid=24940379
In fact, you could probably re-compress a DVD with MPEG-2 (instead of H.264) and get equivalent quality at almost equally low data-rates, simply because the DVD producer's MPEG-2 encoders are terrible, and the settings they use (GOP size, fixed resolution/black borders, high frequency noise, etc.) waste a LOT of the bitrate on things which really don't improve visual quality.
And to be a bit pedantic... H.264 is, in fact "MPEG". It's MPEG-4 AVC (Part10), while DVDs use MPEG-2.
This is the most obvious and boring insight they could possibly offer... Everyone with the slightest interest knows this already.
The low quality of hardware-based video encoder cards is a very well-known fact, and those MPEG encoders cards are just ASICs on a PCI card, almost exactly the same hardware as your video card.
The point of offering up APIs for GPUs, and AMD's attempt to integrate the GPU ASIC with the CPU via HyperTransport, is aimed at improving things, however.
x264 does a good job because it's an open source project, with several skilled and interested individuals continually tweaking the code to improve quality and performance. Once hardware-based video encoding routines aren't hidden in closed-source firmware on a dedicated card, the same development effort can step up and improve HARDWARE encoding now, exactly as they have with software.
Not only can quality be significantly improved, you can expect performance to improve significantly as well, even with greater quality. The initial implementation of any codec is always relatively poor performing, and low quality, so this wouldn't even be an insightful observation if it was comparing x264 with any other software based encoder... The only difference is that a new software h.264/AVC encoder would be SLOWER than x264, as well as being much lower quality.
It is well-known, in economic theory, that some investments return much more money than is spent, as future economy growth.
You could say we're pissing away money on building so many public roads around the country, but all indicators say for every $1 spent on roads, the economy grows by almost $6.
The same is even more true for high technology. Military spending, developing jet aircraft, is directly responsible for the development of the civilian airline industry, particularly jet aircraft. Did we piss away that money, too? Seems like Boeing, Northrup, Lockheed, GE, Pratt&Whitney, etc., bring in a hell of a lot of money... no doubt many times more than the US Gov spent in the first place.
The Apollo program is in large part directly responsible for much of the economic and technological growth this country has seen since the '60s. This program, as well, could jump start the economy. This project in particular could yield a new nuclear reactor design that could potentially be useful here on earth.
First, because NASA rockets have a very high reliability rating. It's going to be very, very rare for one carrying nuclear materials to fail to make orbit.
Second, a small amount of radioactive material being accidentally dispersed, very high in the Earth's atmosphere, would cause it to disperse widely before what's left of it settles down to ground level. Resulting in a minimal increase in the level of natural background radiation. ie. Even if it everything goes wrong, the potential for health effects are minimal, and probably much less significant than something mundane, like having a coal power plant in operation near you.
Third, and primarily, because radioactive material isn't going to just be put in a ziplock bag and dropped on top of a rocket... NASA has a long history of sending up LOTS of radioactive material, but they do so in extremely well-engineered containers. Even sending it to space, where weight is a high premium, the nuclear material casings are extremely robust...
We KNOW it's a extremely robust containment system NASA uses, because there have been several failures, and several of the devices have reentered the atmosphere in the worst possible circumstances, and yet we're not dead. In fact, to the best of my knowledge, despite half a dozen NASA incidents, none of them have resulted in radioactive material being released. It's actually kind of funny... For all the hysteria about radioactive material, Apollo 13's RTG (radioactive thermo-electric generator) is still chugging away on the floor of the Pacific Ocean, not too far off the coast of CA, after falling, uncontrolled, from space.
And finally, because the Russians have been less careful than NASA, and have been dumping radioactive material into our atmosphere for more than 30 years... It happens, and people aren't dropping like flies.
Well, the fact that they're contracting outside Cisco experts now suggests nobody else there was technically competent enough to manage the network.
The fact that the network stayed up and running without a hitch, while he was in jail and nobody else had access, suggests he did know what he was doing, and refusing to allow anyone to access the routers to make changes seems to work quite well to keep the system working.
The fact that his supervisors are moronic and useless is no small thing, either.
His actions were extremely stupid, but I fail to see why this idiot's relatively non-disruptive actions rise to the level of criminal prosecution.
Russian space technology tend to be simple, inefficient, based on the oldest technology they can get away with, and remains unchanged pretty much as long as they aren't forced to improve it.
Russian tech is really the complete polar opposite of NASA tech, so such exchanges very rarely work out.
The core needs to be cooled, but there is absolutely no reason water inherently needs to be used for that purpose. It just happens to be sufficiently cheap and abundant here on Earth that we use it.
I'm hoping people will RTFA before asking stupid question...
Returning to the moon is a dry-run for going to Mars. Mars is further away from the sun, and has lots of nasty dust storms.
Getting anything into space, and all the way out of earth orbit, is monumentally EXPENSIVE.
Digging a big hole in the ground is monumentally CHEAP (at least in relative terms).
The people you've heard from, that are scared of sending radioactive material into space, are monumentally STUPID.
Also, fissile nuclear material is a highly valuable, relatively scarce, and non-renewable resource. It's more than likely that we'll need to dig that stuff up again in a century, and reprocess it. Quite a bit harder to do so if it's on it's way to Pluto.
Steel is used so widely, in large part, because it's cheap... Iron is one of the most abundant elements on the planet. Many other materials exist that are stronger than steel, lighter than steel, handle MUCH higher temperatures, etc., etc.
For a fusion reactor, however, "cheap" isn't going to be all that important... More exotic materials that can better handle high temperatures would be easily within reach when you're able to generate that much power.
The article completely fails to explain why we, for some reason, MUST use some (not-yet invented) form of "steel" for the walls of fusion reactors. Boron Carbide, Tungsten, titanium, etc., sound like much better options for this application. While this article sounds like a flimsy excuse to exploit this anniversary.
Not at all!
We just have to wait until he dies (which will no doubt be on November 5, because God hates us) to cut him open and count his rings.
This study is being done by the University of Bristol, and was first reported at "the British Association Science Festival in Liverpool".
Word will get around shortly, but it's not at all surprising that the UK press gets the first shot at the story.
VP7 is a very good codec (and has been around for a while now), but gets completely ignored, because it's proprietary. Not that On2 wouldn't be happy to do the RAND thing, as well as hand out the source code of VP7 to any company out there willing to pay a small amount of money for it... After all, VP3.2 is open source (Theora) and VP6 is part of Flash v8. And in the past they've often committed to keeping license fees much lower than modern MPEG standards.
But, not being a standard, means economies of scale don't kick in... When you're making a VP7 decoder chip, which is only going to be used in a few million boxes for DVB2 (versus innumerable millions of boxes that are likely to use H.264 at one time or another) the cost of designing the chip, and setting up the plant to produce them, keeps prices quite a bit higher. Hence the rationale for standards.
Still, that's just ONE aspect to keep in mind when selecting the video codec you want to use in your standard, for the next several years. Things like license fees, or performance, may negate that added expense.
My only point being... it's very tricky to chose the ideal codec for any standard. You can't just pick something recent and assume it will be the best option into the future. And planning too much for the "future" may drive up prices and ensure that your standard doesn't get adopted, in the present, and instead dies a slow death on the shelf.
Yes, that's certainly true. However, I would point out that there are actually a pretty good number (albeit a very small percentage of the readership) of experts in just about any field that frequent /. It seems they only poke their heads out on rare occasions, however. This leads to strange phenomenon like an article on (eg.) a new RISC CPU getting lots of mindless, worthless, and inaccurate comments... meanwhile, when the same story gets duped two days later, that second article on the subject gets extremely good comments, extensively detailing internals of microprocessors, and similar. Who knows why?
In addition, there are a few regulars who both know what they're talking about, and seem to comment on /. frequently for whatever their reasons. The two that come to mind are Animats and Doc Ruby, (in addition to myself if I may be so bold), who I frequently see offering accurate insights, even though each has their own shortcomings. eg. http://slashdot.org/comments.pl?sid=954211&threshold=2&mode=nested&cid=24883605
Not very relevant now, since I've already elaborated in much more detail, here, but it does contain a bit more info on HE-AACv2 if you care.
http://slashdot.org/comments.pl?sid=956141&cid=24930875
I don't understand. What's not "practical" about VP7?
I have yet to ever find ANYONE here on /. with whom I can have a rational discussion about codec internals.
Never the less, the last line of my reply is "See the other reply to my earlier comment for details." which you apparently didn't do, or you'd have found a bit more detail.
You're also welcome to look-up subjective benchmark comparisons of H.264/AVC and MPEG-2, which, even if they've biased the test to use old and poor quality MPEG-2 encoders, at the very least, will demonstrate the diminishing returns of H.264/AVC at increased bitrates/quality.
And finally, there are inherent limits that audio and video codecs cannot possibly exceed... For audio, that limit is called "Perceptual Entropy" (PE), and was defined decades ago. Once you exceed PE, you no longer have any hope of reproducing an audio signal that cannot be distinguished from the uncompressed original... You can only hope to make it sound acceptable, the distortions non-obvious, and eliminate sounds that might seem like they don't belong, anyhow. MPEG-1 Layer II audio, as used in DAB, is already quite close to that limit, and 128kbps compression substantially exceeds the PE for 44.1KHz stereo audio.
For video, I will admit I have never heard of such a nice simple term and single study to exactly define the limit... Still, I'd be willing to make an educated guess that the figure is no more than 40:1, because (like PE with audio) a rather sharp tailing-off of improvements can be seen in subjective codec tests when nearing that level of compression, which spans the full range of codecs, no matter the technology used.
As with audio, even early lossy video codecs (like MPEG-2) are sufficiently close to that fundamental limit to make the development of better high-bitrate codecs largely pointless. Instead, the focus has been, and continues to be, on the low-end, where you're simply trying to make it look "good", rather than identical, and can flexibly discard perceptual information in a way that it isn't too... distracting.
There is still some room for debate on the subject, since MPEG-2 doesn't entirely hit the perceptual limits of lossy compression. Still, newer codecs don't have very much room to squeeze better compression out of video, while maintaining high-quality video that is close to being indistinguishable from the original.
But if you want to argue that point with me, you face two further problems... First, I've used H.264/AVC encoders and recent/advanced MPEG-2 encoders plenty, so I can speak pretty conclusively when I say there's not much improvement to be had at high bitrates (but like HE-AACv2, it does an impressive job at very low bitrates). Secondly, I know codec internals pretty well, so I can also attest that H.264/AVC is heavily based on the same technologies as it's predecessors (MPEG-1, MPEG-2), and that all the (terribly CPU-hungry) improvements that have been made (eg. qpel vs half-pel, multiple ref/anchor frames, in-loop deblocking, et al.) simply can't provide very much compressibility improvement with high quality (weakly quantized) materials... The amount of change and randomness is too high for such tricks to be effective, so the encoded error remains the most substantial consumer of bits.
What "upgrade"?
If you or they had an antenna before, it's pretty likely it will continue to work just fine for digital.
Of course there are situations where people needed just VHF, but that's pretty rare. If they needed just UHF, it's pretty unlikely they will now need VHF as well.
Even if you've got such a situation, and they can only watch half the channels they used to, they're not exactly in dire straights because of it.
Still, progress is never without some pain. That doesn't make it a "boondoggle".
So, you're advocating the use of On2's VP7 video codec for DVB2?
A codec always has trade-offs. Making the blanket statement that any one is better than another is simplistic and quite naive.
As I've said repeatedly, even ignoring all else but quality at a given bitrate, H.264/AVC isn't necessarily ANY better than MPEG-2 in this (HDTV) usage case. It's great if you want to broadcast lots of barely legible material using very little bandwidth, but it's not so incredible at high bitrates and high quality.
No amount of technological advancement can resolve a political problem...
As far as sound quality, DAB is very good, actually. The MPEG-1 Layer II audio codec does exceptionally well at high bitrates (192kbps or above is easily CD quality). The big (sound quality) problem is, DAB isn't being used as it was designed.
Switching from all analog to all digital would have freed up tons of radio spectrum, allowing for a lot more channels, even at very high quality. The analog didn't get entirely switched off, however, so that extra space didn't arrive. Then, each station having to maintain a digital station, in addition to their analog signal just became a nuisance, hardly worth spending more money on. So, everybody drops down to the barely tolerable quality levels, to squeeze as many channels into the small amount of spectrum available, and to make each as cheap to operate as possible.
Using the most advanced audio codecs won't solve this problem... You just can't get CD-perfect audio at 128kbps. And even if you could, do you want to bet that broadcasters aren't going to pull the same trick again, and lower the bitrate even further, until the sound quality with the newer codecs is less than FM, and barely tolerable, to save some money and squeeze more channels in?
HE-AACv2 has the same benefits and limitations as H.264/AVC. See the other reply to my earlier comment for details.
You're neglecting to mention parametric stereo (PS).
This is nonsense. If you got better sound quality at a given bitrate, you simply reduce the bitrate further until you get approximately the original quality level.
SBR isn't about preserving high frequencies AT ALL. In fact it's about eliminating the high frequencies completely, and using the low frequencies to guess/approximate what higher frequency content might sound like.
It's a clever perceptual trick (much like intensity joint-stereo), but like most similar tricks, it only works on low-quality content. Once you start increasing the bitrate to the point where regular (low complexity AAC) compression doesn't do terribly, such tricks start to do... worse, and are best simple disabled.
This isn't something I just made up on the spot. See: http://www.ebu.ch/en/technical/trev/trev_305-moser.pdf
Anyone that has owned a dog can tell you that they're better than cats...
Anecdotes are useless.
The fact that there are crappy MPEG-2 encoder out there, and good MPEG-4 encoders, DOES NOT imply that MPEG-2 is therefore, bad.
With MPEG-4 AVC/H.264, you should NEVER see macroblocking, because there's a dynamic in-line deblocking filter defined in the spec... Its required.
However, using a deblocking filter (on MPEG-2 videos) may get rid of the blocks, but that doesn't mean the picture is going to be better. You generally trade blockiness for blurriness, and H.264/AVC is no exception...
The devil is in the details.
You want WATTS, not just Amps, or else they can just halve the voltage and double the amps, with a trivial change to the battery pack.
Battery capacity over time varies SUBSTANTIALLY based on what level of charge is maintained over that period of time, and how many charge/discharge cycles it goes through. With certain types of batteries, how quickly it is discharged each time, and whether memory effects are mitigated by usage patterns, can make a huge difference as well.
Video playback power consumption depends HIGHLY on the software being used (Media Player vs. MPC vs. MPlayer-win), the codec required to decode the video in question, and the bitrate and resolution at which the video was encoded.
Port power consumption can be screwed with as well. Even if they're "ON" doesn't mean they can't effectively shut themselves off when there's no traffic.
Depends on the web browser software, complexity of the pages being view, etc.
Notepad or Office 2007? On Windows 95 or Vista?
An "hours" figure is just as useful as the tests you've described... You're just providing 5 different figures... Average them together, and you've got a single figure again.
An hours figure would still be perfectly useful, if things like advanced power management didn't jump in and screw up the test. Pretty much the same thing as happened with EPA gas mileage figures, and hybrids...
At the very least, a single figure allows you to at least compare usage time from one laptop to another. Even if neither figure is realist, as long as they're both unrealistic in the same way, and to the same degree, they're meaningful when relatively comparing one to another.
They'll leave the old 10 HOURS figure, in huge numbers on the packaging. Then have an asterisks, and a tiny footnote that says "TYPICAL BATTERY LIFE: 4 hours".
You still have the same problem. Now you're simply moving the problem from calculating "battery life" to calculating "power consumption", and leaving consumers with an extra bit of math to do...
"Lowest" power consumption is tricky, because you've now got to define what parts of the machine have to be functional in this minimal state. ie. You'd get a huge boost in battery life if you shut off the LCD screen, backlight, and graphics chip.
Maximum isn't exactly easy, either... Does this include external devices drawing their power from the laptop ports? USB, Firewire, speakers, mouse, etc., it's pretty easy to drive the power consumption WAY up, with a few ridiculously power-hungry external devices.
Battery capacity is pretty trivial, and is already notated on nearly every battery I've ever seen.
As opposed to females who DON'T play video games, which case every male gamer wishes to have sex with...
Although referring to the UK (and explaining why your system isn't as good) you've just described the US DTV switchover precisely...
Digital transmissions (in highdef, no less) in the US have been going on longer than DVB-T transmissions in the UK and most everywhere else in the world. ATSC is also an even OLDER standard than DVB-T by at more than couple years, or perhaps more depending on how you want to look at it.
Indeed. You get to waste twice the bandwidth, having one lowdef channel, and one highdef. And everyone needs to buy a second box if they want to get the latter. ATSC isn't sounding so bad after all.
You'd be wrong. First, because H.264/MPEG-4 AVC simply wasn't available. Secondly, because increased resolution (and/or framerates) brings substantial additional economies with lossy video codecs.
And finally, there's the law of diminishing returns... MPEG-2 is a very good format, and it's very difficult to design something better. H.264/AVC is extremely computationally intensive, and for all that work, you're extremely lucky if you can get twice the compression out of it. In fact, the 2X figure that's commonly cited to explain H.264/AVC's superiority over MPEG-2 really only applies at extremely low bitrates (eg. streaming video), while the two being to converge as bitrate increases...
You can see the same thing with audio... AAC came out at the same time as MPEG-2, and despite more than a decade, there's nothing out there to surpass it. Now, HE-AACv2 is newer, but even those heavily interested in it, openly admit that it's only better at low bitrates, and at 128kbps (for stereo) it provides no improvement over plain AAC (LC-AAC).