As I recall, isn't it also encrypted? Encryption should, ideally, increase the entropy of the data. That should make it more, not less, difficult to compress it.
There is _no_ market there. Games for linux would have to be free in order to achieve any popularity, and free just doesn't work as a good business model for games.
Film costs. If a major release costs between $1500 and $3000 per print in the US, producing 3000 prints takes a large amount of time and money (upwards of $9,000,000.) A staggered release allows time for prints to be returned, inspected, and if undamaged, sent elsewhere.
So adding another market, say, Europe, is even more expensive. Also, subtitles can often require <em>wholly new prints to be manufactured</em>. The subtitles are often on the film itself, for example, The Protector showed with subtitles in the US with subtitles on the film (as opposed to digitally projected subtitles.) For a movie company to add to their existing expenses by making prints of a movie that may not even succeed in the United States. The additional cost could include several thousand more prints, insuring that the subtitling in dozens of languages is accurate (or at least passes some level of quality control.)
I've heard Wolfram Mathematica is just blazing fast, but I don't even bother keeping track of the prices these days. (I hope they still have the $100 student license.)
See, that's not "common," and certainly costs a bit. And even then, it's somewhat a "cross your fingers and hope" with all the different parts. And still, for all the protection HDCP provides, it is negated by the fact that the media on one end will have to be decrypted eventually, so why not just figure out how to crack that and much more leisurely and simply decrypt the media itself? Performing transcoding in real time is possible, no doubt. Probably not with any common hardware, I am all but certain that no video card will accept an HDCP signal and transcode it, or provide anywhere near the bandwidth. And even if you did get the bandwidth, unless you can compress it you will need a server somewhere. And as you mentioned, you would end up with a huge amount of raw data in the meantime, at 355MiB/s, a full length movie may be in excess of 3 TiB. Your RAID stripe would have to comprise at least 6TiB in storage, which would require, if you used the largest drives available, 10 750GB drives.
Common hardware? If those rigs are so damn common, <em>buy me one</em>. I'll pay the 'common' price of between $500 and $2000 for that machine.
You'd have to slow down the content eventually though, wouldn't you? I mean, 1920x1080 at 60fps with 24 bits per pixel is 2,847MiB per second. That's 1920*1080 = 2,073,600 pixels^2 per frame, and that multiplied by sixty seconds equals 124,416,000 pixels^2 per second, and using n pixels^2 = 24n bits we get 2,985,984,000 bits per second. Divide by eight to get bytes, and we have 373,248,000 bytes. That equals 364500 KiB, or ~355.95MiB/second.
That means you'd fill up your multiple GiB buffer in a matter of seconds. Are you using a fast enough hard drive to write it to disc? Even over SATA 3.0Gb/s your actual throughput is right around 300MiB/s. So you're losing 60MiB to the buffer every second, which means for every gigabyte of RAM you have, you can encode raw HD content for another seventeen to eighteen seconds, assuming everything works really well.
Simply put: without realtime compression and probably signal loss, you can't encode that signal on common hardware. Far easier to simply decrypt the HD content on whatever media it's stored on and reencode it at your leisure.
Could a perl hacker explain the code for those of us who can't read crazy?
(No offense, I'm just not a fan of Perl syntax. If you can make working programs out of it, then it's my loss by not being able to debug them if I ever have to use Perl.)
Gold is actually taking out two birds with one stone, as it is known for its lack of reactivity. For that reason it is used in a great deal of computing equipment.
Unfortunately you'll have to alloy it heavily in order to get the $/byte down!
No, really. Google is a big target. Right now, for SEO's, it's a big albeit moving target. That makes work harder for them. If Google opens up a suggestion system expect it to be shut down rather quickly for flooding.
Just imagine what function this deformed and round piece of unknown metal performs in the UFO! It could be the core to a poor gyroscope! It could be some sort of misshapen weapon meant to inflict damage upon suburban homes!
You may consider this an ignorant comment, and if so I apologize, but I was quite certain that Python supported bignum. Shouldn't that obviate the need for a fix to time_t?
First, to make it clear, I'm replying to this to put my post nearer to the top, but that's because I'm egotistical and have a bias towards exaggerating the value of my own posts. So please, feel free to ignore the nice tidbit below:
It appears what TFA is about is incorrect. Why? Google for "share pictures." Picasa is the second ad in the blue box.
Google for "blog." Blogger shows up below the paid ads, as mostly plaintext with a blogger logo.
Google for "videos." Google Video shows up in the blue box, second ad.
Is it just me, or does it seem like they aren't favoring their own ads at all? There might be some algorithm sorting them, as when I search for some other terms Google comes up first (gmail comes up before AOL mail,) but in other cases Google's service shows up last in the paid ads.
It's an infinite regression of cats and mice, not turtles!
But seriously, it seems to me a lot easier to find the function that performs the decryption, which should be easy to find because AES is a common algorithm, see which argument is the input key, and then insert assembly to output that key somehow, store it in a known location in memory, etc. Of course, then it would be their turn to respond by either revoking the key in new releases, or obfuscating the decryption function at a low level, etc.
However, it still seems to me that it would be much easier to edit the machine code than to screw around with context switching and hoping to grab a useful pointer or the key itself.
It sounds like the first battle was won, but it'll be interesting to see what the DRM guys do next.
Not entirely true. XP won't by default allow you to split up the install, but after you've got all the data backed up you can do so, perhaps not 'easily,' but it is possible. Right now C:\Programs Files (among others) is not the same partition as C:\. I do that so that I can keep the Windows folder seperate and more easily defragmented.
NTFS has learned some new tricks over the years, but I will agree it's still far behind Linux filesystem support. (Unless NTFS happens to be your Linux filesystem.)
This is just my opinion, but wouldn't it be incredibly shortsighted for Apple to store original copies encoded in something as poor in quality as their H.264 implementation? The degredation in quality that they would experience every time they shifted standards would be terrible. I imagine that it's much more likely that given how cheap hard drive space is, they store it losslessly and can choose to encode it again however they want.
Slashdot Mirror
As I recall, isn't it also encrypted? Encryption should, ideally, increase the entropy of the data. That should make it more, not less, difficult to compress it.
There is _no_ market there. Games for linux would have to be free in order to achieve any popularity, and free just doesn't work as a good business model for games.
Film costs. If a major release costs between $1500 and $3000 per print in the US, producing 3000 prints takes a large amount of time and money (upwards of $9,000,000.) A staggered release allows time for prints to be returned, inspected, and if undamaged, sent elsewhere.
So adding another market, say, Europe, is even more expensive. Also, subtitles can often require <em>wholly new prints to be manufactured</em>. The subtitles are often on the film itself, for example, The Protector showed with subtitles in the US with subtitles on the film (as opposed to digitally projected subtitles.) For a movie company to add to their existing expenses by making prints of a movie that may not even succeed in the United States. The additional cost could include several thousand more prints, insuring that the subtitling in dozens of languages is accurate (or at least passes some level of quality control.)
I've heard Wolfram Mathematica is just blazing fast, but I don't even bother keeping track of the prices these days. (I hope they still have the $100 student license.)
See, that's not "common," and certainly costs a bit. And even then, it's somewhat a "cross your fingers and hope" with all the different parts. And still, for all the protection HDCP provides, it is negated by the fact that the media on one end will have to be decrypted eventually, so why not just figure out how to crack that and much more leisurely and simply decrypt the media itself? Performing transcoding in real time is possible, no doubt. Probably not with any common hardware, I am all but certain that no video card will accept an HDCP signal and transcode it, or provide anywhere near the bandwidth. And even if you did get the bandwidth, unless you can compress it you will need a server somewhere. And as you mentioned, you would end up with a huge amount of raw data in the meantime, at 355MiB/s, a full length movie may be in excess of 3 TiB. Your RAID stripe would have to comprise at least 6TiB in storage, which would require, if you used the largest drives available, 10 750GB drives.
Common hardware? If those rigs are so damn common, <em>buy me one</em>. I'll pay the 'common' price of between $500 and $2000 for that machine.
Should have previewed! First MiB figure is wrong (copied the wrong value) but the remaining math should be correct.
You'd have to slow down the content eventually though, wouldn't you? I mean, 1920x1080 at 60fps with 24 bits per pixel is 2,847MiB per second. That's 1920*1080 = 2,073,600 pixels^2 per frame, and that multiplied by sixty seconds equals 124,416,000 pixels^2 per second, and using n pixels^2 = 24n bits we get 2,985,984,000 bits per second. Divide by eight to get bytes, and we have 373,248,000 bytes. That equals 364500 KiB, or ~355.95MiB/second.
That means you'd fill up your multiple GiB buffer in a matter of seconds. Are you using a fast enough hard drive to write it to disc? Even over SATA 3.0Gb/s your actual throughput is right around 300MiB/s. So you're losing 60MiB to the buffer every second, which means for every gigabyte of RAM you have, you can encode raw HD content for another seventeen to eighteen seconds, assuming everything works really well.
Simply put: without realtime compression and probably signal loss, you can't encode that signal on common hardware. Far easier to simply decrypt the HD content on whatever media it's stored on and reencode it at your leisure.
|O O O O|O O O O|
:)
|Only as|opposit|
|long as|e sides|
|they |of a |
|meet on|splice |
|O O O O|O O O O|
But if not, what I take home from the theatre can make that happen
Could a perl hacker explain the code for those of us who can't read crazy?
(No offense, I'm just not a fan of Perl syntax. If you can make working programs out of it, then it's my loss by not being able to debug them if I ever have to use Perl.)
That's not a downside, that's taking security through obscurity to a new level.
I don't want to shatter your already fragmented and illusory worldview, but no, not everyone who lives here is a US Citizen.
Gold is actually taking out two birds with one stone, as it is known for its lack of reactivity. For that reason it is used in a great deal of computing equipment.
Unfortunately you'll have to alloy it heavily in order to get the $/byte down!
That creates an interesting positive correlation between elephant population and Web 2.0 citations. And global warming.
Clearly the Elephants are bringing about Web 2.0, and their faeces is causing Global Warming.
Problem solved, where's my prize?
Flooding.
No, really. Google is a big target. Right now, for SEO's, it's a big albeit moving target. That makes work harder for them. If Google opens up a suggestion system expect it to be shut down rather quickly for flooding.
Just imagine what function this deformed and round piece of unknown metal performs in the UFO! It could be the core to a poor gyroscope! It could be some sort of misshapen weapon meant to inflict damage upon suburban homes!
You may consider this an ignorant comment, and if so I apologize, but I was quite certain that Python supported bignum. Shouldn't that obviate the need for a fix to time_t?
Eminent Domain. If there ever were a good case for using it, this would be it.
I think they are assuming Standard Temperature and Pressure.
First, to make it clear, I'm replying to this to put my post nearer to the top, but that's because I'm egotistical and have a bias towards exaggerating the value of my own posts. So please, feel free to ignore the nice tidbit below:
It appears what TFA is about is incorrect. Why? Google for "share pictures." Picasa is the second ad in the blue box.
Google for "blog." Blogger shows up below the paid ads, as mostly plaintext with a blogger logo.
Google for "videos." Google Video shows up in the blue box, second ad.
Is it just me, or does it seem like they aren't favoring their own ads at all? There might be some algorithm sorting them, as when I search for some other terms Google comes up first (gmail comes up before AOL mail,) but in other cases Google's service shows up last in the paid ads.
It's an infinite regression of cats and mice, not turtles! But seriously, it seems to me a lot easier to find the function that performs the decryption, which should be easy to find because AES is a common algorithm, see which argument is the input key, and then insert assembly to output that key somehow, store it in a known location in memory, etc. Of course, then it would be their turn to respond by either revoking the key in new releases, or obfuscating the decryption function at a low level, etc. However, it still seems to me that it would be much easier to edit the machine code than to screw around with context switching and hoping to grab a useful pointer or the key itself. It sounds like the first battle was won, but it'll be interesting to see what the DRM guys do next.
And how fast can they move unladen?
Fixing her best friend's computer is probably more likely to get you in bed with her than making a webserver.
Not entirely true. XP won't by default allow you to split up the install, but after you've got all the data backed up you can do so, perhaps not 'easily,' but it is possible. Right now C:\Programs Files (among others) is not the same partition as C:\. I do that so that I can keep the Windows folder seperate and more easily defragmented. NTFS has learned some new tricks over the years, but I will agree it's still far behind Linux filesystem support. (Unless NTFS happens to be your Linux filesystem.)
Will I finally be able to use a video card with Linux 24.9.12?
This is just my opinion, but wouldn't it be incredibly shortsighted for Apple to store original copies encoded in something as poor in quality as their H.264 implementation? The degredation in quality that they would experience every time they shifted standards would be terrible. I imagine that it's much more likely that given how cheap hard drive space is, they store it losslessly and can choose to encode it again however they want.