The GPL covers the software x264, not the output produced by x264. Nevermind the fact that said logic is extremely dubious (the Software Freedom Law Center, as does basically everyone except the FSF, disagrees with that interpretation).
I like the way some DVD players can play DIVX.
So are you claiming that patents are good or bad? DivX is also known as MPEG-4 Part 2 Advanced Simple Profile... which is heavily patent-encumbered.
The main change in the past year has been the psy optimizations that were added; before the psy optimizations, x264 was roughly on par with Mainconcept, one of the better commercial encoders. The psy optimizations--adaptive quantization and psy-RD (both on by default)--put x264 way over the top. Recently, the new MB-tree algorithm (also on by default) has boosted quality quite a bit as well. The main catch with psy optimizations is that they're nearly impossible to measure mathematically, and in fact, unless you disable them, they will make the "mathematical" measures of quality (mean squared error/PSNR) much worse.
It's always nice when free software solutions trash the commercial alternatives.
If person A and person B both contribute significant code to a program, and person B decides that he wants to sue Company C for infringing his copyright, how does Person A have the right to stop him? Even if Person A doesn't care about Company C infringing his copyright, Company C is still infringing Person B's copyright, and Person B can still sue them.
(IANAL)
I find that music is fine as long as your mind doesn't focus too much on it. If I listen to similar music long enough it becomes a bit like breathing; it's there but I don't really notice it. It's actually quite odd; if my mind is properly defocused, I can listen to a mix containing 10 songs, all of which I know, and then be unable to pick more than half of them after the fact!
As for benefits, I'm not sure; I think it keeps me from going insane, which is probably a good enough reason.
Though sometimes when I have to focus really hard on something very difficult to visualize, I end up having to turn off the music.
There's been an enormous improvement in the Linux scheduler in recent months--in some cases the performance improvements are as high as 60-80% with simple multithreaded apps like video encoders. The instant 2.6.32 comes out officially, expect to start seeing some completely absurd results in stupid "comparisons between Linux distros" like these, where the distros that happened to update to.32 trash the ones that haven't yet.
Murdoch seems to think that people use Google to search Murdoch's sites.
By Murdoch's logic, clearly if he withdraws his sites from Google, people will stop using Google to search his sites. But hardly anyone using Google has the intention of "searching his sites". People just want information--most people don't care which site has the information as long as it's good information. If Murdoch pulls out of Google that just means fewer people will visit Murdoch's sites. Nobody is going to give a toss about the fact that Fox won't show up on Google.
This entire strategy suggests that Murdoch misunderstands his own readers.
Japanese amateur (doujin) artists have been self-publishing professional-quality albums for years now. No RIAA, no middlemen: they set up a booth at a convention and sell it. And then, afterwards, they sell extra copies from their website. It seems to work well enough: some single fandoms have produced hundreds if not thousands of albums.
Isn't it amazing what you can do when you prioritize actually making music over trying to get rich?
And don't think that the Japanese have it easier with regard to music copyright enforcement: the problem is actually so great there that file-traders have been forced to use anonymous P2P systems like Share and Winny.
There are pretty much three choices for streaming video right now:
1. Crappy encoder, low bitrate. This is what Youtube went with originally--they used FLV1 (Sorenson H.263) video, which at the time was the only real option (other than VP6, which wasn't much better). They went with 350kbps video. The result was pretty awful, but it worked for Youtube videos. It's free, so people will tolerate it. But for a paid service, such quality is absurd.
2. Crappy encoder, high bitrate. This is what Stage6 did; they used DivX, which, while better than FLV1, wasn't too much better. But what they did was allow absurdly high bitrates; I saw bitrates over 12 megabits per second for standard definition video! Of course, we all know what happened to Stage6; upon realizing the sheer amount of money that such bitrates cost, they went out of business, sort of like Wile. E. Coyote falling to the ground only after realizing that he was standing on air.
3. Good encoder, low bitrate. Facebook does ~600kbps standard definition video, and it looks great. Vudu does 1080p video on demand at 2.8mbps. Youtube now does 720p HD at 2 megabits. What do they have in common? They use x264 for encoding.
NetFlix chose to use VC-1 instead, and as a result they have 1.5 megabit standard definition streams that look like crap. And they don't even have an excuse anymore, because Silverlight supports H.264. Which is rather odd, actually, as Microsoft has been pushing for years to try to replace H.264 in the marketplace with their vastly inferior VC-1. Maybe they've given up because their campaign just isn't working.
The people who work on it are--surprise--the same people making the commercial games.
They contribute because its *beneficial to everyone* to make the game engine better and more versatile. They don't make more money by withholding their features from other developers.
Games and open source have made great bedfellows for quite some time.
A great example is Kirikiri, an open source (GPL) adventure game/visual novel scripting engine used in many popular Japanese games, including Fate/Stay Night, one of the most popular games of the genre. Fate/Stay Night, if it even has to be mentioned, made bucketloads of money and was successful enough to spawn a massive franchise including an anime, many sequel games, a novel series, and more.
The idea that somehow games and open source can't work together is ridiculous and simply false.
6-8 megabits is plenty for 1080p H.264 if you're using a sane encoder. I've made demos as low as 3 megabits without serious artifacting.
NBC uses MPEG-2, not H.264, which is why it sucks so much at lower bitrates.
They were hand coded before we used the macros to abstract them (which involved deleting over half the code!). Of course, that's not all of it, since a significant amount of assembly has been written since the abstraction was done. Though you're also not counting the Altivec assembly, which is rather significant also.
No, the wrapper is not being linked to. Linking has a very specific meaning--and linking was not being done. Calling a binary via "exec" is not linking. If it was, the GPL would truly be a dangerous license! (And yes, Avail does distribute software containing GPL'd products, its not internal-use-only).
x264 uses an abstraction method in order to lump enormous amounts of assembly into very small amounts of space. But when all the macros are expanded, it gets much, much, much larger. For example, almost all the SSE/MMX assembly is abstracted away into macros, so a few macros can be used to take a single generic function and expand it into SSE or MMX. Same with 32-bit vs 64-bit. When you expand it all fully, it is indeed tens of thousands of lines.
In my experience HCEnc, a freeware encoder (not open-source though), tends to beat CCE quality-wise. Most of Doom9 seems to agree, though I don't think the differences were too dramatic.
No, they're encoding. Transcoding means you're reusing syntax elements from the original video to inform the encoder; i.e. you're not entirely decoding it (not repeating all the process of encoding). What they're doing is encoding, because they're decoding it entirely into a raw video stream, and then sending that into the encoder.
I wouldn't say football's real challenge is motion either--motion search is a rather simple part of most encoders and IMO definitely not the biggest challenge. The challenge of football is not decimating the grass, which requires both a strong adaptive quantization algorithm and also benefits from psychovisual optimizations that bias towards sharpness (such as x264's experimental "psy-RD").
That isn't really how video encoding works; the only "probabilities" are in the CABAC entropy encoder, which is handled via the method of arithmetic coding (which indeed isn't SIMD'd).
LGPL vs GPL is not actually a very big issue in my experience. I spent the summer working at Avail Media, a company that uses x264 for real-time 1080i/720p broadcast encoding for IPTV and cable television (and also funds a large portion of x264 development). They use x264 in their encoding boxes--yet their main application is proprietary! This is done by having an extremely simple open-source wrapper which is statically linked to x264; the raw frames to be encoded are passed to it over a pipe by the main program. This completely bypasses the limitations of the GPL without violating the spirit of it, since anyone who wants to can still read the source code of the wrapper, modify it, and recompile it as necessary and still use it with the main application.
There is a huge business made around building payware GUIs that (often silently, without giving any credit, sometimes violating GPL/LGPL) do nothing but use open-source tools to do their work. This is especially true in video encoding where there is are almost no cheap proprietary tools--only the extremely widely used open source solutions and extremely expensive "professional" ones (with some rare exceptions like DivX and Nero). Usually these GUIs are much worse than the free ones, but a sucker's born every minute.
This isn't 1990 anymore; CPUs have SIMD just as graphics cards do. A modern CPU doing even a brute-force exhaustive motion search can come out on par with a GPU in terms of performance. And if you use sequential elimination instead of a brute-force search (which gives a mathematically equivalent output), a single Core 2 Quad can outperform a quad-SLI set of top-end graphics cards. Sequential elimination, however, despite being SIMD-able, is not well-suited to the threading model of CUDA and similar APIs, and so probably cannot be implemented reasonably on a GPU.
This concept applies to many algorithms--the brute-force method is easily implementable on a GPU, but a faster and algorithmically smarter method is not well-suited to such an architecture.
Most of the operations in video encoding are most definitely parallelizable on both a large and small scale, both in regards to frame-based threading, used by many encoders and decoders, but also especially in regards to SIMD (x264 has tens of thousands of lines of handwritten assembly).
Yet that line brings up yet another problem--they're using the absolute latest software from Elemental, but are using a 7-month-old version of x264 that is lacking an enormous number of recent improvements. Its anything but a fair test.
Slashdot Mirror
The GPL covers the software x264, not the output produced by x264. Nevermind the fact that said logic is extremely dubious (the Software Freedom Law Center, as does basically everyone except the FSF, disagrees with that interpretation).
I like the way some DVD players can play DIVX. So are you claiming that patents are good or bad? DivX is also known as MPEG-4 Part 2 Advanced Simple Profile... which is heavily patent-encumbered.
It's exactly the same as with any other encoder that you use for Blu-ray authoring.
The main change in the past year has been the psy optimizations that were added; before the psy optimizations, x264 was roughly on par with Mainconcept, one of the better commercial encoders. The psy optimizations--adaptive quantization and psy-RD (both on by default)--put x264 way over the top. Recently, the new MB-tree algorithm (also on by default) has boosted quality quite a bit as well. The main catch with psy optimizations is that they're nearly impossible to measure mathematically, and in fact, unless you disable them, they will make the "mathematical" measures of quality (mean squared error/PSNR) much worse.
It's always nice when free software solutions trash the commercial alternatives.
If person A and person B both contribute significant code to a program, and person B decides that he wants to sue Company C for infringing his copyright, how does Person A have the right to stop him? Even if Person A doesn't care about Company C infringing his copyright, Company C is still infringing Person B's copyright, and Person B can still sue them. (IANAL)
I find that music is fine as long as your mind doesn't focus too much on it. If I listen to similar music long enough it becomes a bit like breathing; it's there but I don't really notice it. It's actually quite odd; if my mind is properly defocused, I can listen to a mix containing 10 songs, all of which I know, and then be unable to pick more than half of them after the fact!
As for benefits, I'm not sure; I think it keeps me from going insane, which is probably a good enough reason.
Though sometimes when I have to focus really hard on something very difficult to visualize, I end up having to turn off the music.
There's been an enormous improvement in the Linux scheduler in recent months--in some cases the performance improvements are as high as 60-80% with simple multithreaded apps like video encoders. The instant 2.6.32 comes out officially, expect to start seeing some completely absurd results in stupid "comparisons between Linux distros" like these, where the distros that happened to update to .32 trash the ones that haven't yet.
But those people aren't Googling for things; they're heading to the Fox page directly.
Murdoch seems to think that people use Google to search Murdoch's sites.
By Murdoch's logic, clearly if he withdraws his sites from Google, people will stop using Google to search his sites. But hardly anyone using Google has the intention of "searching his sites". People just want information--most people don't care which site has the information as long as it's good information. If Murdoch pulls out of Google that just means fewer people will visit Murdoch's sites. Nobody is going to give a toss about the fact that Fox won't show up on Google. This entire strategy suggests that Murdoch misunderstands his own readers.
Japanese amateur (doujin) artists have been self-publishing professional-quality albums for years now. No RIAA, no middlemen: they set up a booth at a convention and sell it. And then, afterwards, they sell extra copies from their website. It seems to work well enough: some single fandoms have produced hundreds if not thousands of albums.
Isn't it amazing what you can do when you prioritize actually making music over trying to get rich?
And don't think that the Japanese have it easier with regard to music copyright enforcement: the problem is actually so great there that file-traders have been forced to use anonymous P2P systems like Share and Winny.
There are pretty much three choices for streaming video right now:
1. Crappy encoder, low bitrate. This is what Youtube went with originally--they used FLV1 (Sorenson H.263) video, which at the time was the only real option (other than VP6, which wasn't much better). They went with 350kbps video. The result was pretty awful, but it worked for Youtube videos. It's free, so people will tolerate it. But for a paid service, such quality is absurd.
2. Crappy encoder, high bitrate. This is what Stage6 did; they used DivX, which, while better than FLV1, wasn't too much better. But what they did was allow absurdly high bitrates; I saw bitrates over 12 megabits per second for standard definition video! Of course, we all know what happened to Stage6; upon realizing the sheer amount of money that such bitrates cost, they went out of business, sort of like Wile. E. Coyote falling to the ground only after realizing that he was standing on air.
3. Good encoder, low bitrate. Facebook does ~600kbps standard definition video, and it looks great. Vudu does 1080p video on demand at 2.8mbps. Youtube now does 720p HD at 2 megabits. What do they have in common? They use x264 for encoding.
NetFlix chose to use VC-1 instead, and as a result they have 1.5 megabit standard definition streams that look like crap. And they don't even have an excuse anymore, because Silverlight supports H.264. Which is rather odd, actually, as Microsoft has been pushing for years to try to replace H.264 in the marketplace with their vastly inferior VC-1. Maybe they've given up because their campaign just isn't working.
The people who work on it are--surprise--the same people making the commercial games.
They contribute because its *beneficial to everyone* to make the game engine better and more versatile. They don't make more money by withholding their features from other developers.
Games and open source have made great bedfellows for quite some time.
A great example is Kirikiri, an open source (GPL) adventure game/visual novel scripting engine used in many popular Japanese games, including Fate/Stay Night, one of the most popular games of the genre. Fate/Stay Night, if it even has to be mentioned, made bucketloads of money and was successful enough to spawn a massive franchise including an anime, many sequel games, a novel series, and more.
The idea that somehow games and open source can't work together is ridiculous and simply false.
6-8 megabits is plenty for 1080p H.264 if you're using a sane encoder. I've made demos as low as 3 megabits without serious artifacting. NBC uses MPEG-2, not H.264, which is why it sucks so much at lower bitrates.
They were hand coded before we used the macros to abstract them (which involved deleting over half the code!). Of course, that's not all of it, since a significant amount of assembly has been written since the abstraction was done. Though you're also not counting the Altivec assembly, which is rather significant also.
No, the wrapper is not being linked to. Linking has a very specific meaning--and linking was not being done. Calling a binary via "exec" is not linking. If it was, the GPL would truly be a dangerous license! (And yes, Avail does distribute software containing GPL'd products, its not internal-use-only).
x264 uses an abstraction method in order to lump enormous amounts of assembly into very small amounts of space. But when all the macros are expanded, it gets much, much, much larger. For example, almost all the SSE/MMX assembly is abstracted away into macros, so a few macros can be used to take a single generic function and expand it into SSE or MMX. Same with 32-bit vs 64-bit. When you expand it all fully, it is indeed tens of thousands of lines.
In my experience HCEnc, a freeware encoder (not open-source though), tends to beat CCE quality-wise. Most of Doom9 seems to agree, though I don't think the differences were too dramatic.
No, they're encoding. Transcoding means you're reusing syntax elements from the original video to inform the encoder; i.e. you're not entirely decoding it (not repeating all the process of encoding). What they're doing is encoding, because they're decoding it entirely into a raw video stream, and then sending that into the encoder.
I wouldn't say football's real challenge is motion either--motion search is a rather simple part of most encoders and IMO definitely not the biggest challenge. The challenge of football is not decimating the grass, which requires both a strong adaptive quantization algorithm and also benefits from psychovisual optimizations that bias towards sharpness (such as x264's experimental "psy-RD").
That isn't really how video encoding works; the only "probabilities" are in the CABAC entropy encoder, which is handled via the method of arithmetic coding (which indeed isn't SIMD'd).
LGPL vs GPL is not actually a very big issue in my experience. I spent the summer working at Avail Media, a company that uses x264 for real-time 1080i/720p broadcast encoding for IPTV and cable television (and also funds a large portion of x264 development). They use x264 in their encoding boxes--yet their main application is proprietary! This is done by having an extremely simple open-source wrapper which is statically linked to x264; the raw frames to be encoded are passed to it over a pipe by the main program. This completely bypasses the limitations of the GPL without violating the spirit of it, since anyone who wants to can still read the source code of the wrapper, modify it, and recompile it as necessary and still use it with the main application.
There is a huge business made around building payware GUIs that (often silently, without giving any credit, sometimes violating GPL/LGPL) do nothing but use open-source tools to do their work. This is especially true in video encoding where there is are almost no cheap proprietary tools--only the extremely widely used open source solutions and extremely expensive "professional" ones (with some rare exceptions like DivX and Nero). Usually these GUIs are much worse than the free ones, but a sucker's born every minute.
This isn't 1990 anymore; CPUs have SIMD just as graphics cards do. A modern CPU doing even a brute-force exhaustive motion search can come out on par with a GPU in terms of performance. And if you use sequential elimination instead of a brute-force search (which gives a mathematically equivalent output), a single Core 2 Quad can outperform a quad-SLI set of top-end graphics cards. Sequential elimination, however, despite being SIMD-able, is not well-suited to the threading model of CUDA and similar APIs, and so probably cannot be implemented reasonably on a GPU.
This concept applies to many algorithms--the brute-force method is easily implementable on a GPU, but a faster and algorithmically smarter method is not well-suited to such an architecture.
Most of the operations in video encoding are most definitely parallelizable on both a large and small scale, both in regards to frame-based threading, used by many encoders and decoders, but also especially in regards to SIMD (x264 has tens of thousands of lines of handwritten assembly).
Yet that line brings up yet another problem--they're using the absolute latest software from Elemental, but are using a 7-month-old version of x264 that is lacking an enormous number of recent improvements. Its anything but a fair test.