Well, Kazaa is cheap if you don't value your time or bandwidth. But considering how many badly encoded or just wrong files out there, and how slow transfer can be, anyone with a job is better off just paying for the songs and knowing they'll come down right the first time, off a high QoS server. I can't imagine ever downloading something off Kazaa if it was commerically available.
Better user experience is definitely a good place for the legit services to provide value.
I'm reminded of what my dad always said about going to see movies: "why pay now, when you can wait for a few years and it'll be free on television?" But I want it now, and good!
Of course, SGI's failure was more of execution than strategy. First, they "Osborned" themselves by not making it clear what the long-term strategy was for Irix, reducing sales of their existing product lines. They also reduced R&D on IRIX/MIPS, giving them less of a way out if the NT strategy failed.
Then, more importantly, they built machines that were techically overambitious, with cool sounding memory technology that was a compatibilty and stability nightmare in practice. While the SGI NT boxes sounded great, they just didn't do the job in the real world.
Also, NT as a digital media platform was a little too early. It wasn't until Windows 2000 before that kernel really became competitive for video, for example.
And once all that failed, they'd spent a huge portion of their available capital, which was sunk, and they had to reinvigorate IRIX and MIPS, which was a real challenge. SGI would be a lot bigger today if they hadn't ever bothered with x86/NT.
Sun has made their long term Solaris/SPARC plan very clear. Also, they're using Linux, over which they have some measure of control to make sure the OS supports their hardware perfectly, instead of a propritary OS. I think this is a good strategy, and has a significant chance of working. Interesting they're using Linux and not Solaris for Intel, though.
Maybe others do doubles, but AltiVec is only singles. There are proofs-of-concept for how to double-up to fake doubles with AltiVec, but it isn't via native support.
Except most 3D applications use 64-bit floating point, but AltiVec only supports 32-bit floating point.
Which isn't a big deal, really, with the 970's two FPUs. AltiVec does 128 bits at once, so it could only two 64-bit FP operations at once anyway, if it supported it.
Final Cut Pro 4 will support 32-bit floating point for image processing, which is a very nice fit for AltiVec.
Will Linux apps become AltiVec enabled?
on
More on the PowerPC 970
·
· Score: 3, Interesting
Well, Linux and its apps don't have much AltiVec optimization because AltiVec wasn't in many Linux chips. But if IBM or licensees start making 970 based Linux workstations, it seems this would be likely to change.
And this would be a good thing for Apple, since there would be a lot more *NIX codec that could compile and run a LOT faster on their boxes, and there would be a larger pool of AltiVec and PPC coding talent for them and their ISVs to draw from.
The linked article is generally pretty good, but I found one rather glaring omission. When testing AVC (called H.26L in the artcle), they only used a single reference frames. One of the most important features of AVC is its support for multiple reference frames. These work by allowing the codec to do motion estimation from multiple previous frames (3 in the baseline profile, 5 in the higher profiles). This helps compression efficiency a lot with things like muzzle flashes, spinning fans, or anything else where part of the image is obscured, and then revealed again.
But using only one reference frame, their testing wouldn't have been able to approach the theoretical quality the codec is capable of.
Still, VP6 looks to be an excellent codec. And supporting multiple references frames is expensive in terms of CPU power and memory requirements, so there are reasons why they wouldn't have wanted to us it in VP6.
While the software demo is on Windows, On2 has made codecs for multiple platforms before, and certainly can do so again. Bear in mind this demo is to get people to LICENSE the codec. I'm sure they'd be happy to port the codec to whatever for a licensee writing a sufficiently large check.
SV3 isn't an MPEG-4 codec. Sorenson has a (very good) MPEG-4 Simple and Advanced Simple implementation, but it still doesn't have the compression efficiency of SV3.1 at lower bitrates.
Xvid uses the Simple and Advanced Simple profiles of MPEG-4. These were extensions of baseline H.263 (aka MPEG-4 short header), but with LOTS of enhancements.
FWIW, H.263 is the standard video codec used in videoconferencing system. Most of the IRAQ video was using it.
All MPEG-4 codecs are patent-encumbered, and will require license fees in some circumstances. However, these tend not to be too onerous. For example, today's MPEG-4 video codecs are free for the first 50,000 units distributed per year.
Actually, those encode times aren't that bad at all for a development codec. Back when I started doing professional encoding (1994), we targeted 80 minutes of render time per minute of source files, so a feature film would be more like a week of computer time. Still had a very viable business based around that.
Of course, that was with 80 MHz computers...
LOTS of companies are working on AVC implementations, and they'll certainly compete on speed. There's lots of areas in the standard where speed/quality tradeoffs can be used.
Actually, H.264 is manifestly NOT patent free. There may be a license-fee free baseline profile for it, but it's certain that the higher profiles will have some kind of license fee ala the current MPEG-4 codec.
Still, that certainly doesn't kill a format in every case. Every DVD player pays $2.50 to MPEG-LA.
I've got.mac. It works fine for lots of stuff, but trying to do a backup over DSL is effectively impossible. And for a lot of corporate stuff, it makes more sense to do things inside the subnet rather than have them on a server out in the world.
Personlly, I think they should add local.mac services into Mac OS X Server. It'd be a nice value add for workgroups, while still giving stand-alone consumers a reason to pay the big bugs.
Nah, not really. There is only so big an app can get in terms of code, and it's way, way less than a small HD can do. For consumers, who are using more than 25% or so for their drive, it's likely digital media that's doing it. MP3 files, and especially video. Textures and videos in games. Tutorial files for media apps. That kind of stuff.
Crack open your average 20 MB MacOS X.app, and you'll likely find less than 25% of the total file is being used for application code. The rest is multilingual help, graphics, sounds, etcetera.
Re:License comparison EULA's likely unenforceable
on
Video Codec Comparison
·
· Score: 1
Well, I'm a compression nerd, not a server nerd, which is why I don't write something like that. I can't imagine that publications that cover this space aren't preparing just such articles.
Microsoft's various PR agencies are all very good, and provide excellent support in software, technical contacts, etcetera for folks working on articles. I doubt they'd let this clause become a problem.
Which again begs the question of why it is in there.
5x better than MPEG-2? Not a good MPEG-2! A cutting-edge MPEG-2 encoder (try Canopus ProCoder) using 2-pass encoding, and taking advantage of the modes than downloadble files support (like square pixel progressive encoding) could give pretty good results at the data rates the article is looking at - certainly nowhere near 5x worse. MPEG-2's biggest limitation is lack of a deblocking filter, so distracting block artifacts start showing up a lot below a certain point.
At NAB I demoed a 1280x720 24p 4 Mbps MPEG-2 file, and it looked pretty darn good. Not as good as the best MPEG-4 advanced simple, but it wasn't night and day, more like 2pm and 4pm.
I agree that the differences at these data rates are getting smaller and smaller. The big differences these days are at higher resolutions or lower bitrates, or files tuned for streaming (with a constrained buffer) instead of download (where codecs can move bits around within a file with abandon).
Actually.mp4.mov. The MPEG-4 file format is based on QuickTime, but they made some changes and enhancements that broke backwards compatibility. QuickTime provides a transparent conversion for apps that use their own API, but other.mov tools will need an update to use.mp4.
The QuickTime MPEG-4 encoder is actually pretty bad (single pass only, speed instead of quality tuned). Sorenson Squeeze, Envivio Encoding Station, and plenty of other tools can make a QuickTime-compatible MPEG-4 file without a hitch, and with much better compression efficiency.
MPEG-2 will last, but software decoders for it aren't nearly as ubiquitous as for MPEG-1. So if archiving content that doesn't need MPEG-2 (which means no interlacing), I'd go for MPEG-1. But if it does have interlacing, go for MPEG-2.
I don't think that.avi solutions are good for the long term. it isn't an ISO standard, and also not very good. AVI is already a legacy format outside of the ripping community. I'd go for a real.mp4 file.
Well, the MPEG-2 part 2 codecs (the one's you've seen so far) are really suped-up versions of the H.263 videoconferencing codecs. It uses a lot of the same concepts as MPEG-2, but tuned for better performance at lower data rates. The new AVC MPEG-4 codec (which is what the 2004 version of this article will likely be about) is way better than both, and not based on either. Lots of whacky new stuff like multiple reference frame (so you can predict parts of the current frame on a frame THREE back, for example. Very nice with muzzle flashes!).
I write a lot of codec review articles for DV Magazine. My editors tell me not to worry about those EULA's. Not only are the "no review" clauses considered largely unenforceable, there are any number of magazines out there who whould love to be the test case on this stuff.
Disregarding the legal issues, it's be a huge PR nightmare if a company actually started suing users for discussing how the products work. I can't imagine why they put the clauses in there. It's alienates users without actually gaining any real protection.
Actually, the codec is too late in the process. The internal workflow is:
Decode -> Filter -> encode
The filter step includes cropping, scaling, inverse telecine, etcetera. ideally, deblocking should be done at the decode stage, where the codec knows where the macroblock boundaries are, and so can better discriminate between artifacts and image elements. If it's done at the codec stage, the encoder won't know anything about the original source, and must use much more ham-fisted filters.
Well, a modern high-end Hollywood DVD is going to be pretty clean. Given all the other filtering going on in preprocessing, the artifacts don't wind up being THAT big a deal. In a head to head comparision between uncompressed source and a professionally mastered DVD of the same source, the end-point will be pretty similar. Also, since all the codecs used the same source, it was still an apples-to-apples comparison.
Still, it befuddles me how much time people are willing to spend copying a DVD that only costs $18 in the first place...
Slashdot Mirror
Well, Kazaa is cheap if you don't value your time or bandwidth. But considering how many badly encoded or just wrong files out there, and how slow transfer can be, anyone with a job is better off just paying for the songs and knowing they'll come down right the first time, off a high QoS server. I can't imagine ever downloading something off Kazaa if it was commerically available.
Better user experience is definitely a good place for the legit services to provide value.
I'm reminded of what my dad always said about going to see movies: "why pay now, when you can wait for a few years and it'll be free on television?" But I want it now, and good!
Of course, SGI's failure was more of execution than strategy. First, they "Osborned" themselves by not making it clear what the long-term strategy was for Irix, reducing sales of their existing product lines. They also reduced R&D on IRIX/MIPS, giving them less of a way out if the NT strategy failed.
Then, more importantly, they built machines that were techically overambitious, with cool sounding memory technology that was a compatibilty and stability nightmare in practice. While the SGI NT boxes sounded great, they just didn't do the job in the real world.
Also, NT as a digital media platform was a little too early. It wasn't until Windows 2000 before that kernel really became competitive for video, for example.
And once all that failed, they'd spent a huge portion of their available capital, which was sunk, and they had to reinvigorate IRIX and MIPS, which was a real challenge. SGI would be a lot bigger today if they hadn't ever bothered with x86/NT.
Sun has made their long term Solaris/SPARC plan very clear. Also, they're using Linux, over which they have some measure of control to make sure the OS supports their hardware perfectly, instead of a propritary OS. I think this is a good strategy, and has a significant chance of working. Interesting they're using Linux and not Solaris for Intel, though.
Maybe others do doubles, but AltiVec is only singles. There are proofs-of-concept for how to double-up to fake doubles with AltiVec, but it isn't via native support.
Except most 3D applications use 64-bit floating point, but AltiVec only supports 32-bit floating point.
Which isn't a big deal, really, with the 970's two FPUs. AltiVec does 128 bits at once, so it could only two 64-bit FP operations at once anyway, if it supported it.
Final Cut Pro 4 will support 32-bit floating point for image processing, which is a very nice fit for AltiVec.
Well, Linux and its apps don't have much AltiVec optimization because AltiVec wasn't in many Linux chips. But if IBM or licensees start making 970 based Linux workstations, it seems this would be likely to change.
And this would be a good thing for Apple, since there would be a lot more *NIX codec that could compile and run a LOT faster on their boxes, and there would be a larger pool of AltiVec and PPC coding talent for them and their ISVs to draw from.
The linked article is generally pretty good, but I found one rather glaring omission. When testing AVC (called H.26L in the artcle), they only used a single reference frames. One of the most important features of AVC is its support for multiple reference frames. These work by allowing the codec to do motion estimation from multiple previous frames (3 in the baseline profile, 5 in the higher profiles). This helps compression efficiency a lot with things like muzzle flashes, spinning fans, or anything else where part of the image is obscured, and then revealed again.
But using only one reference frame, their testing wouldn't have been able to approach the theoretical quality the codec is capable of.
Still, VP6 looks to be an excellent codec. And supporting multiple references frames is expensive in terms of CPU power and memory requirements, so there are reasons why they wouldn't have wanted to us it in VP6.
While the software demo is on Windows, On2 has made codecs for multiple platforms before, and certainly can do so again. Bear in mind this demo is to get people to LICENSE the codec. I'm sure they'd be happy to port the codec to whatever for a licensee writing a sufficiently large check.
On2 are a bunch of good, old school codec guys.
SV3 isn't an MPEG-4 codec. Sorenson has a (very good) MPEG-4 Simple and Advanced Simple implementation, but it still doesn't have the compression efficiency of SV3.1 at lower bitrates.
Also, Apple and Sorenson settled this suit/countersuit quite a while ago.
Xvid uses the Simple and Advanced Simple profiles of MPEG-4. These were extensions of baseline H.263 (aka MPEG-4 short header), but with LOTS of enhancements.
FWIW, H.263 is the standard video codec used in videoconferencing system. Most of the IRAQ video was using it.
All MPEG-4 codecs are patent-encumbered, and will require license fees in some circumstances. However, these tend not to be too onerous. For example, today's MPEG-4 video codecs are free for the first 50,000 units distributed per year.
Actually, those encode times aren't that bad at all for a development codec. Back when I started doing professional encoding (1994), we targeted 80 minutes of render time per minute of source files, so a feature film would be more like a week of computer time. Still had a very viable business based around that.
Of course, that was with 80 MHz computers...
LOTS of companies are working on AVC implementations, and they'll certainly compete on speed. There's lots of areas in the standard where speed/quality tradeoffs can be used.
Actually, H.264 is manifestly NOT patent free. There may be a license-fee free baseline profile for it, but it's certain that the higher profiles will have some kind of license fee ala the current MPEG-4 codec.
Still, that certainly doesn't kill a format in every case. Every DVD player pays $2.50 to MPEG-LA.
I've got .mac. It works fine for lots of stuff, but trying to do a backup over DSL is effectively impossible. And for a lot of corporate stuff, it makes more sense to do things inside the subnet rather than have them on a server out in the world.
.mac services into Mac OS X Server. It'd be a nice value add for workgroups, while still giving stand-alone consumers a reason to pay the big bugs.
Personlly, I think they should add local
Nah, not really. There is only so big an app can get in terms of code, and it's way, way less than a small HD can do. For consumers, who are using more than 25% or so for their drive, it's likely digital media that's doing it. MP3 files, and especially video. Textures and videos in games. Tutorial files for media apps. That kind of stuff.
.app, and you'll likely find less than 25% of the total file is being used for application code. The rest is multilingual help, graphics, sounds, etcetera.
Crack open your average 20 MB MacOS X
Well, I'm a compression nerd, not a server nerd, which is why I don't write something like that. I can't imagine that publications that cover this space aren't preparing just such articles.
Microsoft's various PR agencies are all very good, and provide excellent support in software, technical contacts, etcetera for folks working on articles. I doubt they'd let this clause become a problem.
Which again begs the question of why it is in there.
Ach, you're right.
http://www.radgametools.com/binksdk.htm
I had thought they were working on that, but it appears not.
5x better than MPEG-2? Not a good MPEG-2! A cutting-edge MPEG-2 encoder (try Canopus ProCoder) using 2-pass encoding, and taking advantage of the modes than downloadble files support (like square pixel progressive encoding) could give pretty good results at the data rates the article is looking at - certainly nowhere near 5x worse. MPEG-2's biggest limitation is lack of a deblocking filter, so distracting block artifacts start showing up a lot below a certain point.
At NAB I demoed a 1280x720 24p 4 Mbps MPEG-2 file, and it looked pretty darn good. Not as good as the best MPEG-4 advanced simple, but it wasn't night and day, more like 2pm and 4pm.
I agree that the differences at these data rates are getting smaller and smaller. The big differences these days are at higher resolutions or lower bitrates, or files tuned for streaming (with a constrained buffer) instead of download (where codecs can move bits around within a file with abandon).
Actually .mp4.mov. The MPEG-4 file format is based on QuickTime, but they made some changes and enhancements that broke backwards compatibility. QuickTime provides a transparent conversion for apps that use their own API, but other .mov tools will need an update to use .mp4.
The QuickTime MPEG-4 encoder is actually pretty bad (single pass only, speed instead of quality tuned). Sorenson Squeeze, Envivio Encoding Station, and plenty of other tools can make a QuickTime-compatible MPEG-4 file without a hitch, and with much better compression efficiency.
MPEG-2 will last, but software decoders for it aren't nearly as ubiquitous as for MPEG-1. So if archiving content that doesn't need MPEG-2 (which means no interlacing), I'd go for MPEG-1. But if it does have interlacing, go for MPEG-2.
.avi solutions are good for the long term. it isn't an ISO standard, and also not very good. AVI is already a legacy format outside of the ripping community. I'd go for a real .mp4 file.
I don't think that
Well, the MPEG-2 part 2 codecs (the one's you've seen so far) are really suped-up versions of the H.263 videoconferencing codecs. It uses a lot of the same concepts as MPEG-2, but tuned for better performance at lower data rates. The new AVC MPEG-4 codec (which is what the 2004 version of this article will likely be about) is way better than both, and not based on either. Lots of whacky new stuff like multiple reference frame (so you can predict parts of the current frame on a frame THREE back, for example. Very nice with muzzle flashes!).
I write a lot of codec review articles for DV Magazine. My editors tell me not to worry about those EULA's. Not only are the "no review" clauses considered largely unenforceable, there are any number of magazines out there who whould love to be the test case on this stuff.
Disregarding the legal issues, it's be a huge PR nightmare if a company actually started suing users for discussing how the products work. I can't imagine why they put the clauses in there. It's alienates users without actually gaining any real protection.
Actually, the codec is too late in the process. The internal workflow is:
Decode -> Filter -> encode
The filter step includes cropping, scaling, inverse telecine, etcetera. ideally, deblocking should be done at the decode stage, where the codec knows where the macroblock boundaries are, and so can better discriminate between artifacts and image elements. If it's done at the codec stage, the encoder won't know anything about the original source, and must use much more ham-fisted filters.
Well, a modern high-end Hollywood DVD is going to be pretty clean. Given all the other filtering going on in preprocessing, the artifacts don't wind up being THAT big a deal. In a head to head comparision between uncompressed source and a professionally mastered DVD of the same source, the end-point will be pretty similar. Also, since all the codecs used the same source, it was still an apples-to-apples comparison.
Still, it befuddles me how much time people are willing to spend copying a DVD that only costs $18 in the first place...