Don't let wavelet vs DCT fool you. That's not the hard part of making a scalable video codec, and you can drop subbands from DCT too if you code the coefficients in the right order.
For compressing an individual image, wavelets provide automatic scalability: you can downscale by a power of 2 by dropping some subbands without recompressing. But that isn't sufficient for video. If you just downscale each frame, that essentially introduces intermediate rounding in the motion compensation process, and that rounding quickly accumulates to a very ugly distortion.
H.264 has an extension called SVC which addresses such scalability. SVC isn't widely implemented because it's recent and complex (as if H.264 weren't complex enough already), but it at least in theory works. On the other hand, Dirac does not even in principle support scalability.
.. video codecs used in consumer video systems (even H.264/Blu-Ray) do not have such high color depth. So what's the point?
There's nothing wrong with the codecs; H.264 supports up to 14bpc (42bpp). The consumer applications (Blu-Ray) just decided not to use that feature. And the decision must be due in part to the rarity of >24bpp displays.
The practical suggestion I made is that we thus use one of these alternative voting systems for primaries, and do a simple 2-party final election. That would eliminate the spoiler effect, while not penalizing people to freely vote for 3rd party candidates.
You're not taking Arrow seriously enough. The combination of a primary and a 2-party final election is itself a multi-party election and can be gamed like any other multi-party election. Consider that it's identical to a single election where each ballot consists of: some votes for the primary (however you planned to run that) and a set of final votes (one for every possible outcome of the primary). Now, you may like such a runoff voting system (it is after all one of the alternatives), but your proposal is no different than using one of these alternative voting systems for the whole election.
After activating all the cells in parallel, you're left with N bits saying which rows matched. You have reduced the constant factor from comparing a whole table entry to comparing 1 bit. But that doesn't change the asymptotic complexity; you still have to search through all those rows to find the first match. That search (the encoder in your diagram) is what has a delay of log(N). Unless you're claiming you can build a million-input AND gate that's just as fast as a 2-input AND gate? The only reason you can sort of get away with calling it O(1) is that in practice N is limited. According to your link, a typical table size is N=30000. log2(N)=15. 15 gate delays isn't an excessive cycle time, and for larger machines the O(N) hardware cost and power consumption would become prohibitive long before the O(log(N)) latency does. But that's a cop-out, because any algorithm is O(1) if N is limited.
A TCAM is a special kind of static ram where a request is processed across all cells in the same cycle in order to produce the best match. Not only does it return a routing decision in O(1), it returns that decision in exactly one clock cycle.
A TCAM is O(log(N)) too, it just has a really small constant term. Sure it completes in one cycle, but the length of that cycle is proportional to the number of bits in the address of a cell, i.e. log(N). Furthermore, according to our current understanding of the laws of physics, any computation at all is at least O(N^(1/3)) for really large N: In order to store N instances of anything you need volume proportional to N, and lightspeed delay is then proportional to the radius.
So disproving the Extended Church-Turing Thesis is harder than you might think. Your description of the process is correct, I'm just nit-picking your example.
That has nothing to do with if vs switch. The compiler could apply the same optimization to a sequence of if/else statements that follow the same restrictions as switch. Likewise, Perl's new switch operator doesn't require the cases to be constant, but your optimization could still apply when they are. I'm not saying the current Perl interpreter does, just that the optimization is independent of the syntax.
In that sense, h.264/aac (which has been through a process where the participants developing the standard are obligated to disclose all covered patents) [...] holds less business risk for device manufacturers like Nokia. Being torpedoed by a submarine patent is expensive, so going the mpeg/iso/iec/itu path and paying a license fee to mpeg-la is seen as safer.
But h.264 is still subject to submarine patents. The disclosure process was not binding on companies that weren't involved in the standard, and had just happened to previously "invent" some algorithm or technology that got used. Unless you're just hoping that h.264 is already popular enough that any patent trolls would already have cashed in, while an equivalent Theora/Vorbis patent troll would still be waiting?
Eventually, I'd love to see a way to do this that doesn't require the fog, like maybe using lasers to intersect at a single point in 3D space in such a way that the polarization reflects the light back to the viewer at that point, while remaining invisible elsewhere.
Photons don't interact with photons. It doesn't matter whether it's lased, polarized, or whatever; two or more beams of light will just pass through each other. (This is also, btw, why photons aren't regularly used as qubits in a quantum computer. It's easy to make them coherent, but you can't compute anything if your qubits don't interact.)
Wouldn't work. If the program merely checks for the presence of a dongle, that can be cracked as easily as anything else, and only increases the hassle for legitimate customers. A cryptographically secure dongle just means you can't impersonate the dongle. You can still delete all the dongle-related code from the program. Dongles are secure if and only if they actually contain part of the program logic, and the executable on disk doesn't contain that logic. (Bonus points if you use a custom chip to accelerate some computation.) Then a potential cracker would have to reimplement that code in order to remove the dongle. But that eliminates any option of only sometimes using the dongle; the program can't run without it.
Being thick (and out of coffee) how the hell can any thing be infinitely precise?
The result will still eventually be stored back into a floating-point number. What it means for an intermediate computation to be infinitely precise is just that it doesn't discard any information that wouldn't inherently be discarded by rounding the end result. When you multiply two finite numbers, the result has only as many bits as the combined inputs. So it's quite possible for a computer to keep all of those bits, then perform the addition with that full precision, and then chop it back to 32bits. As opposed to implementing the same operation with current instructions, which would be: multiply, (round), add, (round).
I haven't ever tried to crack copy protection by inserting code from a demo, but I have cracked copy protection without it, and from that experience I don't think having an unprotected demo would help.
Once you get to the point where you can modify the exe, the hard part of the crack is over. Whatever the protection checks, whether it's some data on the CD or a registry key or some more complex signature of your machine, it's just a branch instruction somewhere and can be NOPed out. Finding the branch is easy too, since you can just run the game with and without whatever it checks for, and see where the execution paths diverge. The (marginally) effective part of a copy protection scheme like SecuROM is use of encryption, compression, and self-modifying code, which make it hard to examine or modify the exe. If you have an unprotected demo exe and a protected retail exe, you can't even compare them until after breaking the protection.
Sure there's the extreme case where the demo and the final version are exactly the same code and differ only in data files, then dropping the whole demo exe into the retail installation would crack it. But as the sibling posters explained, that's rare.
You're looking for the Open Graphics Project. But hardware is hard to design and expensive to fab, you're not going to get an Xtreme3D Graphics Accelerator competitive with the latest from NVIDIA or ATI.
It means that GPLv3 code is cut off from a lot of applications, for example, use in running medical devices where you absolutely want to prohibit anyone from changing the binaries GPLv3 says that if anyone can change the software on the device, then the end user has to have that ability too. But if you want to prohibit anyone from changing the binaries, that's easy: install them in ROM.
because of provisions for distributing keys, any device containing GPLv3 software is no longer certifiable The modified version has to run, it doesn't have to be certified. Unless your certification means that non-certified version are prohibited from performing some functions? In that case it's precisely what GPLv3 is intended to prevent, and we only disagree on whether that's a good thing.
Blue Pill doesn't necessarily have to be on the drive at all, it could be purely in memory, and in a section of memory that never swaps out. Sure in that case you could remove Blue Pill just by rebooting, but if you never detected Blue Pill you might also never have patched the hole by which you got infected, so it can repeat. The only generic way I can think of to defeat that is: Install your own Blue Pill first, and have it inspect any later attempt to use the virtualization functions.:)
Well thats defined as a certian number of times a cesium atom 'wobbles' between 2 different defined states which are defined by yet another measurement. How do we know that we have these measurements right?
Atomic excitation levels are discrete. As long as our measurements are precise enough to distinguish the two levels, any error cascade stops there. Sure the calibration of a second depends on how precisely we can measure the excitations, but there's no error involved in what we're measuring.
How is that roundabout? HuffYUV is lossless in about the simplest way possible: it uses a reversible transform (gradient or Paeth prediction), and doesn't quantize the residual.
Now, if you want a roundabout lossless codec, see WavPack's hybrid mode. It's a lossy perceptual audio codec, that also supports putting the information thrown away by the lossy compression into another file, and the two files can be combined for lossless reconstruction.
Yes, h.263 is a subset of MPEG-4 part2. Note, however, that h.263 has some extensions of its own called h.263+, and h.263+ is not a subset of MPEG-4 part2.
You can already implement DRM in a GPLv3 program. The GPLv3 just says you can't sue anyone for breaking your DRM using your code. And it just so happens that if you implement DRM in a GPLv3 program, breaking will tend to be easy. So what would change if the courts ruled that nothing counts as an "effective technological protection mechanism"? That paragraph of the GPLv3 would become redundant. You'd still be allowed to break DRM, and it would still be easy to break any DRM that has an OSS implementation. The only difference is that you'd also be allowed to break non-GPL systems.
Quoting RMS's explanation of the latest draft:
GPLv3 ensures you are free to remove the handcuffs. It doesn't forbid DRM, or any kind of feature. It places no limits on the substantive functionality you can add to a program, or remove from it. Rather, it makes sure that you are just as free to remove nasty features as the distributor of your copy was to add them.
Because it's faster to pass args in registers than to pass args on the stack. And if any given function needs to spill some args onto the stack to free up registers, that takes no more time or space than if the caller did the same spilling. Whereas leaf functions may use the args in-place, without touching the stack.
Why not drop 387 stack support at all - wouldn't that improve context switching times? (Hmm, I may be wrong here).
The 387 stack is the same space as the mmx registers (That's why you can't mix 387 ops with mmx ops, they clobber each other). So in order to reduce the amount of data that needs to be saved in a context switch, you would have to drop mmx support too. And mmx isn't obsolete. Sure, xmm registers are wider, but mmx is faster for any operation that only needs 8 byte vectors.
When you buy Galactic Civilizations 2, there is no DRM at all. Instead, you get a serial number that entitles you to game updates.
How does that work? I would have thought that if you know where to acquire a pirated version of the initial game, you could also get a pirated version of the update the same way. Are you just depending on the pirates to not redistribute the update?
There's no problem with decoding MP3 in a fixed buffer size. Each frame contains exactly 1152 audio samples.
The MP3 problem you might be thinking of is the bit reservoir: Constant bitrate MP3 only pretends to be constant bitrate. If you look at the spacing between MP3 frame headers it looks like each frame is exactly the same size. But they're really not: frames can borrow bits from nearby frames, so the compressed data at one place in the stream doesn't necessarily decode to the decompressed samples that nominally correspond with that frame. Thus it's tricky to determine where you have to start decoding if you want to seek to a given sample number, and the naive seeking method could be off by about +/- 0.25 seconds.
That problem is specific to MP3; I don't know of any other audio format that suffers from it. All Vorbis had to do to fix it was be logical and put each bit in the frame it's supposed to be in, not in some random other frame.
[quote]Doesn't this make H.264 only free of the two patents held by Qualcomm?[/quote] Right.
[quote]There has to be dozens and dozens of other patents used as AFAIK H.264 is just a profile (AVC) of MPEG-4?[/quote] Yes, there are lots of other patents involved in H.264, but that has nothing to do with the rest of MPEG-4. MPEG-4 is only a name; H.264 would be just as patent encumbered if it didn't share the name with 20 other standards.
First of all removing the signature would means you couldn't compute the step sizes, and thus you couldn't correctly decode the file. And if the file was reencoded, you might still be able to extract the watermark by comparing with the original uncompressed movie. You would just have to find enough of the places where quality was increased. (And enough is a lot less than all of them). The problem with that is: Video compression does not inherently produce constant quality. Most codecs vary the quality over time, either to limit bitrate and/or to produce a video that looks better (i.e. constant perceptual quality instead of mathematical quality). But the copyright holder doesn't know exactly what quality allocation heuristic is used by the pirate's codec (which is dependent not only on which version of which program he uses, but also which parameters and filters he adds, making an exponential number of combinations). Thus the parts of the transcoded movie that are highest quality will not correspond even vaguely with the parts that the watermark chose.
All the real robust watermark algorithms have one thing in common: The watermark is encoded by munging some feature that a transcoder would try to preserve, such as color, texture, motion, timing, etc. Using a feature that the transcoder intentionally modifies (like DCT coefficient precision) is bound to fail.
You don't have to have flash to use Google Video, you know. Yes, Google Video displays a flash movie player if you have flash. (At least I assume the SWF link is a movie player; I don't have flash installed so I've never seen it in action). But it also provides links to AVI/MPEG4/MP3 and MP4/H264/AAC versions (called "Download for Windows/Mac" and "Download for Video iPod/Sony PSP", respectively).
Slashdot Mirror
Don't let wavelet vs DCT fool you. That's not the hard part of making a scalable video codec, and you can drop subbands from DCT too if you code the coefficients in the right order.
For compressing an individual image, wavelets provide automatic scalability: you can downscale by a power of 2 by dropping some subbands without recompressing. But that isn't sufficient for video. If you just downscale each frame, that essentially introduces intermediate rounding in the motion compensation process, and that rounding quickly accumulates to a very ugly distortion.
H.264 has an extension called SVC which addresses such scalability. SVC isn't widely implemented because it's recent and complex (as if H.264 weren't complex enough already), but it at least in theory works. On the other hand, Dirac does not even in principle support scalability.
Probably not what the OP was thinking of, but I did find some related literature. 2nd hit on google, actually:
Optimizing Sorting with Genetic Algorithms, by X. Li, M.J. Garzaran, and D. Padua, in Proc. of the International Symposium on Code Generation and Optimization, pages 99-110, March 2005
You're not taking Arrow seriously enough. The combination of a primary and a 2-party final election is itself a multi-party election and can be gamed like any other multi-party election. Consider that it's identical to a single election where each ballot consists of: some votes for the primary (however you planned to run that) and a set of final votes (one for every possible outcome of the primary). Now, you may like such a runoff voting system (it is after all one of the alternatives), but your proposal is no different than using one of these alternative voting systems for the whole election.
After activating all the cells in parallel, you're left with N bits saying which rows matched. You have reduced the constant factor from comparing a whole table entry to comparing 1 bit. But that doesn't change the asymptotic complexity; you still have to search through all those rows to find the first match. That search (the encoder in your diagram) is what has a delay of log(N). Unless you're claiming you can build a million-input AND gate that's just as fast as a 2-input AND gate?
The only reason you can sort of get away with calling it O(1) is that in practice N is limited. According to your link, a typical table size is N=30000. log2(N)=15. 15 gate delays isn't an excessive cycle time, and for larger machines the O(N) hardware cost and power consumption would become prohibitive long before the O(log(N)) latency does. But that's a cop-out, because any algorithm is O(1) if N is limited.
A TCAM is O(log(N)) too, it just has a really small constant term. Sure it completes in one cycle, but the length of that cycle is proportional to the number of bits in the address of a cell, i.e. log(N).
Furthermore, according to our current understanding of the laws of physics, any computation at all is at least O(N^(1/3)) for really large N: In order to store N instances of anything you need volume proportional to N, and lightspeed delay is then proportional to the radius.
So disproving the Extended Church-Turing Thesis is harder than you might think. Your description of the process is correct, I'm just nit-picking your example.
That has nothing to do with if vs switch. The compiler could apply the same optimization to a sequence of if/else statements that follow the same restrictions as switch. Likewise, Perl's new switch operator doesn't require the cases to be constant, but your optimization could still apply when they are. I'm not saying the current Perl interpreter does, just that the optimization is independent of the syntax.
But h.264 is still subject to submarine patents. The disclosure process was not binding on companies that weren't involved in the standard, and had just happened to previously "invent" some algorithm or technology that got used. Unless you're just hoping that h.264 is already popular enough that any patent trolls would already have cashed in, while an equivalent Theora/Vorbis patent troll would still be waiting?
Photons don't interact with photons. It doesn't matter whether it's lased, polarized, or whatever; two or more beams of light will just pass through each other.
(This is also, btw, why photons aren't regularly used as qubits in a quantum computer. It's easy to make them coherent, but you can't compute anything if your qubits don't interact.)
Wouldn't work.
If the program merely checks for the presence of a dongle, that can be cracked as easily as anything else, and only increases the hassle for legitimate customers. A cryptographically secure dongle just means you can't impersonate the dongle. You can still delete all the dongle-related code from the program.
Dongles are secure if and only if they actually contain part of the program logic, and the executable on disk doesn't contain that logic. (Bonus points if you use a custom chip to accelerate some computation.) Then a potential cracker would have to reimplement that code in order to remove the dongle. But that eliminates any option of only sometimes using the dongle; the program can't run without it.
The result will still eventually be stored back into a floating-point number. What it means for an intermediate computation to be infinitely precise is just that it doesn't discard any information that wouldn't inherently be discarded by rounding the end result.
When you multiply two finite numbers, the result has only as many bits as the combined inputs. So it's quite possible for a computer to keep all of those bits, then perform the addition with that full precision, and then chop it back to 32bits. As opposed to implementing the same operation with current instructions, which would be: multiply, (round), add, (round).
I haven't ever tried to crack copy protection by inserting code from a demo, but I have cracked copy protection without it, and from that experience I don't think having an unprotected demo would help.
Once you get to the point where you can modify the exe, the hard part of the crack is over. Whatever the protection checks, whether it's some data on the CD or a registry key or some more complex signature of your machine, it's just a branch instruction somewhere and can be NOPed out. Finding the branch is easy too, since you can just run the game with and without whatever it checks for, and see where the execution paths diverge.
The (marginally) effective part of a copy protection scheme like SecuROM is use of encryption, compression, and self-modifying code, which make it hard to examine or modify the exe. If you have an unprotected demo exe and a protected retail exe, you can't even compare them until after breaking the protection.
Sure there's the extreme case where the demo and the final version are exactly the same code and differ only in data files, then dropping the whole demo exe into the retail installation would crack it. But as the sibling posters explained, that's rare.
You're looking for the Open Graphics Project. But hardware is hard to design and expensive to fab, you're not going to get an Xtreme3D Graphics Accelerator competitive with the latest from NVIDIA or ATI.
Blue Pill doesn't necessarily have to be on the drive at all, it could be purely in memory, and in a section of memory that never swaps out. Sure in that case you could remove Blue Pill just by rebooting, but if you never detected Blue Pill you might also never have patched the hole by which you got infected, so it can repeat. :)
The only generic way I can think of to defeat that is: Install your own Blue Pill first, and have it inspect any later attempt to use the virtualization functions.
Atomic excitation levels are discrete. As long as our measurements are precise enough to distinguish the two levels, any error cascade stops there. Sure the calibration of a second depends on how precisely we can measure the excitations, but there's no error involved in what we're measuring.
How is that roundabout?
HuffYUV is lossless in about the simplest way possible: it uses a reversible transform (gradient or Paeth prediction), and doesn't quantize the residual.
Now, if you want a roundabout lossless codec, see WavPack's hybrid mode. It's a lossy perceptual audio codec, that also supports putting the information thrown away by the lossy compression into another file, and the two files can be combined for lossless reconstruction.
Yes, h.263 is a subset of MPEG-4 part2. Note, however, that h.263 has some extensions of its own called h.263+, and h.263+ is not a subset of MPEG-4 part2.
So what would change if the courts ruled that nothing counts as an "effective technological protection mechanism"? That paragraph of the GPLv3 would become redundant. You'd still be allowed to break DRM, and it would still be easy to break any DRM that has an OSS implementation. The only difference is that you'd also be allowed to break non-GPL systems.
Quoting RMS's explanation of the latest draft: GPLv3 ensures you are free to remove the handcuffs. It doesn't forbid DRM, or any kind of feature. It places no limits on the substantive functionality you can add to a program, or remove from it. Rather, it makes sure that you are just as free to remove nasty features as the distributor of your copy was to add them.
Because it's faster to pass args in registers than to pass args on the stack. And if any given function needs to spill some args onto the stack to free up registers, that takes no more time or space than if the caller did the same spilling. Whereas leaf functions may use the args in-place, without touching the stack.
The 387 stack is the same space as the mmx registers (That's why you can't mix 387 ops with mmx ops, they clobber each other). So in order to reduce the amount of data that needs to be saved in a context switch, you would have to drop mmx support too. And mmx isn't obsolete. Sure, xmm registers are wider, but mmx is faster for any operation that only needs 8 byte vectors.
How does that work? I would have thought that if you know where to acquire a pirated version of the initial game, you could also get a pirated version of the update the same way. Are you just depending on the pirates to not redistribute the update?
There's no problem with decoding MP3 in a fixed buffer size. Each frame contains exactly 1152 audio samples.
The MP3 problem you might be thinking of is the bit reservoir: Constant bitrate MP3 only pretends to be constant bitrate. If you look at the spacing between MP3 frame headers it looks like each frame is exactly the same size. But they're really not: frames can borrow bits from nearby frames, so the compressed data at one place in the stream doesn't necessarily decode to the decompressed samples that nominally correspond with that frame. Thus it's tricky to determine where you have to start decoding if you want to seek to a given sample number, and the naive seeking method could be off by about +/- 0.25 seconds.
That problem is specific to MP3; I don't know of any other audio format that suffers from it. All Vorbis had to do to fix it was be logical and put each bit in the frame it's supposed to be in, not in some random other frame.
[quote]Doesn't this make H.264 only free of the two patents held by Qualcomm?[/quote]
Right.
[quote]There has to be dozens and dozens of other patents used as AFAIK H.264 is just a profile (AVC) of MPEG-4?[/quote]
Yes, there are lots of other patents involved in H.264, but that has nothing to do with the rest of MPEG-4. MPEG-4 is only a name; H.264 would be just as patent encumbered if it didn't share the name with 20 other standards.
All the real robust watermark algorithms have one thing in common: The watermark is encoded by munging some feature that a transcoder would try to preserve, such as color, texture, motion, timing, etc. Using a feature that the transcoder intentionally modifies (like DCT coefficient precision) is bound to fail.
You don't have to have flash to use Google Video, you know. Yes, Google Video displays a flash movie player if you have flash. (At least I assume the SWF link is a movie player; I don't have flash installed so I've never seen it in action). But it also provides links to AVI/MPEG4/MP3 and MP4/H264/AAC versions (called "Download for Windows/Mac" and "Download for Video iPod/Sony PSP", respectively).