At the end of the clip, they play the Fender guitar through an amp. Sounds out of tune to me (being a real guitar, it needs tuning if you want to play it through an amp), but I could be mistaken.
Reviews seem to indicate that pro mode for guitar with one of these things is a bit more analog than the whole notes-scrolling-down-screen thing, so you might be able to do more tricks than you'd think.
By whose definition? A FOSS h.264 encoder would still adhere to all four of GNU's freedoms. GNU does not state that you must be free to charge money for it, only that you must be free to run it, free to (re)distribute it, free to study/change it, and free to distribute your modified versions of it to others. Nowhere does it say that you must be free to charge money for it without having to pay someone else.
The GNU certainly states that you must not be required to pay to do any of these four things, but charging money is not one of these four things. The distribution is still unrestricted, and since you can't use FOSS software in a non-FOSS commercial work, the freedom to distribute that commercial work with the h.264 encoder is unaffected.
It seems you're partially right. Harmonix is claiming that they only currently support one MIDI guitar (the Squier), but there doesn't seem to be any reason why the story should be different for any other MIDI guitar. Regardless, the Squier costs half as much as any other MIDI guitar, and will offer a far more realistic gameplay experience than the YouRock device, since the YouRock lacks real strings (somewhat important for a guitar).
You can toss together a solution for $200-300 per unit (not including server cost) by throwing a generic Linux distro with NX installed onto an embedded PC and be done with it. It's pretty trivial and common place stuff...
Not only did you not read correctly, you missed the point. The "proprietary" label was not applied to MP3 or AAC, but "other proprietary formats". WMA might be an example. And the point wasn't that it was more or less proprietary, but that MP3 had been largely supplanted by newer codecs.
It's 150MHz wide, so three. That's not really an issue in home use (other than that it'll blow out any 802.11n networks trying to use that spectrum), but makes it useless for public use.
At that point, the crazy bandwidth/spectrum use is a bigger problem than the costs of solving it. Perceptually lossless video compression could get that down to 5% of the bandwidth used (I challenge anybody to tell the difference between 150Mbps 1080p60 video and uncompressed video) if you need fullscreen video, and remote desktop solutions (particularly those like NX that send text as text) are much better if all you need is some sort of status display.
In 40MHz of 802.11n space, I could take thirty nx-based thin clients that are small enough to mount on the rear of a monitor and still have plenty of bandwidth left over.
Any wifi thin client should do, since they don't rely on whole-frame video compression. It's a lot more optimal to send text *as* text (as many remote desktop solutions like X or NX do) than to send a video of the text. You'll get more than 30m of range (or rather, with a higher base range, given the same amount of interference, it'll go farther than WHDI), and you can have a lot more active clients than WHDI, which can only support three clients (40MHz channels in a 150MHz band) at a time.
No, there are exactly the same chances of being sued for implementing it: zero. The chances are also zero if you free distribute a FOSS encoder. You only need a license to *sell* an h.264 encoder.
The fact that you can only fit three full 40Mhz channels in the unlicensed 5GHz space, and that the range of this stuff is optimally 30m, means that it will be completely useless for what you describe. There are existing wireless display technologies that are enormously more effective for that sort of thing.
Pixel response times are not the same thing as input latency. IPS panels seem to be worse in this regard. There were a few relatively recent high-end Dell monitors that had multiple frames worth of latency.
Latency on wireless mice hasn't been an issue since the Fast RF was introduced in 2002. Your desktop LCD panel probably has far more latency than a good Fast RF mouse.
True. I'll admit that I relied on the stated goals of each generation of codec rather than actual benchmarks. I'd note that the claimed efficiency improvement for Samsung+BBC is 40%, rather than 20-30%. This also obviously doesn't take encoder improvements into effect, as x264 is pretty advanced in thsi regard.
This doesn't really change my overall point, though. If MPEG-4 AVC achieves 2x the efficiency of MPEG-2, and Samsung+BBC is (let's split the difference) 1.3x as efficient as AVC, then we're currently 2.6x the efficiency of MPEG-2. This reinforces the point that there's room for improvement left.
Even if nobody is ever sued for VP8, and it turns out to be patent free in effect, that doesn't change the fact that there are major issues with it. All the patent-avoidance necessitated a rather steep decrease in efficiency (since most techniques that could improve efficiency are patented, unfortunately), and the VP8 spec is still rather buggy.
Google's biggest mistake was not bothering to write a proper spec, making the encoder the spec. The problem we're saddled with now is that the encoder is always behaving per-spec since it *is* the spec. Bugs in the encoder can't be fixed, and Google has already rejected valid bug fixes for the decoder because the encoder's broken behaviour is per-spec.
h.264 can't do VHS quality at 50Kbps, especially not if you include audio.
I might agree with 150-200Kbps, but even that's going to have to use special low-bitrate audio codecs like HE-AAC where the upper frequencies and stereo information is sort of faked. It was claimed that WMV9 (the basis for VC-1, which is closer to MPEG-4 ASP than h.264) claimed they could do VHS-quality at 250Kbps, and that was stretching the truth a bit.
As to get back to your original question, "You think there's a codec more advanced than MPEG4-derived 264?", the successor to h.264, HEVC, is targeting a doubling in efficiency, and is scheduled to be finalized by 2012. Doubling of efficiency would mean that the same quality is achieved with half the bitrate.
As was pointed out in other comments, nyquist/shannon have nothing at all to do with perceptual video compression. We'll reach a point some day when throwing more computational power and newer algorithms at the problem won't make much difference, but we're *VERY* far from that point today. There's a huge amount of room for improvement. The fact that we're still doubling efficiency with every codec generation (MPEG-2 -> MPEG-4 ASP -> MPEG-4 AVC -> HEVC each doubled efficiency) should be proof enough of that.
MP3 is popular for home use, but is virtually unused in terms of commercial use relative to AAC and other proprietary formats. JPEG remains popular because it reached the point where it was "good enough", with later competing codecs not offering a sufficient advantage to justify the pain of trying to move everybody to a new format. MPEG-2's video codec is still used in DVDs, and is *supported* by bluray, but BluRays encoded with MPEG-2 is extremely rare (pretty much everything is h.264 or VC1, mostly h.264).
Audio and still-image compression is not a field where large gains can be had so easily. If I produce a still-image codec that is 25% more efficient, then maybe I can save 5300 images on my SD card instead of 4000... but that's not going to make much difference. Same in terms of audio; I don't really care if my MP3 player can store 388 hours of audio or 517 hours. Audio has reached the point where we tend to encode everything at the same bitrate regardless of compression efficiency. In fact, uncompressed digital audio isn't exactly rare. CDs aren't compressed, and increasingly movies ship with lossless audio. We've reached a cap in terms of audio quality (more data doesn't help), but storage capacities keep going up.
Video, on the other hand, is a big deal. In terms of streaming, the amount of bandwidth required to compress good quality 1080p video still exceeds the connection speed of most broadband connections in north America (let alone disc-quality). On top of that, there's an increasing trend towards bandwidth caps.
Bell Canada in Ontario has a 25GB cap on usage. If we assume 5Mbps video (enough for 720p, at least), a consumer can only afford to watch about 23 minutes of video per day. If you double the compression efficiency (as the successor to h.264 aims to do), that becomes a *very* big deal. You can afford to stream much higher quality video to those with limited connection speeds, or stream a lot more video to those with limited transfer caps, or store more content on a disc. The impact would be felt enormously almost anywhere video is used.
Getting back to replacing h.264, let's examine a bit about how long it took h.264 to become ubiquitous. It's mostly replaced previous codecs, as it's now the dominant codec for consumer consumption. Your cellphone and video camera record to it, your disc-based movies use it, increasingly your television service uses it, your streaming video uses it, etc. h.264 was standardized in 2003. 7 years later, it's unquestionably the dominant standard. This was even true a year or two ago, so we might stretch this a bit and say that 5 years was enough for h.264 to go mainstream.
h.264's sucessor, HVEC, is scheduled to be finalized in 2012, with a targeted improvement over h.264 of 100% (same quality at 50% bitrate) By 2020, 8 years will have passed since "h.265" was standardized. At that point, I would fully expect it to be the dominant codec in use.
Google's motivation is obviously to try to establish an open source, free (as in speech) codec as the web standard for video.
Then Google picked the wrong codec to buy/push. WebM is likely to be just as patent-encumbered as h.264, since large parts of the VP8 spec were poorly ripped from h.264's spec, or are at least similar enough to be covered by many of the same patents.
A good examination on a technical level (including some thoughts on the likeliness of patent-encumbrance) can be seen here. He's admittedly a tad biased by being one of x264's lead developers, but he's also one of the authors of ffvp8, and it's an interesting read.
Of particular worry is the flawed nature of the VP8 spec; the reference implementation *is* the spec, bugs and all. Google didn't allow for any time to try to correct/improve the spec before declaring it final, so now we're all stuck with .
Sad news for the web, that we'll be saddled with outdated inefficient codecs that, at least in the case of WebM, are probably just as patent-encumbered as h.264.
It's a proper electric guitar, with a phono jack for plugging into an amp, but it can also be used as an RB3 controller via the official MIDI adapter.
Of course, the same is true of *any* cheap MIDI electric guitar, but this thing costs half as much as the cheapest MIDI guitars, and has some game-related buttons on it too that get properly mapped via the guitar->MIDI->RB3 chain.
Precedents usually have to come from the same country...
IANAL. We don't have mass lawsuits in Canada like they do in the US. This isn't to say that the CRIA didn't try, but when they experimentally sued their first 29 filesharers in 2004, the judge (who incidentally is now chairperson of our telecoms regulator, the CRTC) ruled against their request for disclosure of the identities of the alleged fileshares. The cases then obviously were dead in the water, and I don't believe any have been filed since.
If you're interested in the reasons why the judge rejected the CRIA's request, the reasons why the request violated the rules established for such disclosures were:
1) The CRIA had hired a third party company, MediaSentry, to do the investigations, and the affadavit alleging evidence of infringement was signed by the president of this company, rather than the employees who did the investigation. As such, alleged evidence was hearsay, and not admissible.
2) MediaSentry had employed decoy music files, but did not verify that the alleged infringers had downloaded the actual songs in question and not the decoys, which they weren't being sued for. As such, no evidence was provided that the files in question were even the plaintiff's infringed files.
3) The CRIA alleged that the infringement was performed by various Kazaa usernames, but provided no evidence as to how they associated these usernames to the IPs for which they were seeking discovery. As such, there is no evidence that the IP was involved in the infringement.
4) The copyright act states that reproduction of an audio recording for private use by the copier does not constitute copyright infringement, and so the alleged downloading of the MP3 files did not constitute copyright infringement
5) No evidence was provided that the alleged infringers had distributed or authorized the reproduction of the files, merely that they had placed personal copies in a location that was accessible to others, and this does not constitute copyright infringement. Others accessing the accessible files is not copyright infringement, the user must take a positive act of sending the files themselves.
6) The CRIA alleged secondary infringement, but didn't even try to establish knowledge on the part of the defendants
7) The lawsuits were filed long after the infringement was alleged to have taken place (about a year), and retrieving the information requested (contact info of the person using the IP at the time) over such a long period of time was not practical or reasonable, and quite likely not even possible. Furthermore, the contact info of the account holder that owned the IP is not necessarily the same as the person who committed the infringement on the computer.
8) The great length of time between the alleged infringement and the filing of the lawsuit causes privacy concerns to outweigh the copyrights of the plaintiffs, since they gave no reason as to why they waited so long. I think the idea here was that clearly the damage caused wasn't terribly important since they waited so long.
The ruling in the end denies the CRIA's motion, and granted costs to the ISPs who participated. So the CRIA's attempt to try mass lawsuits US-style imploded in a spectacular manner. Without major changes to Canadian law, such lawsuits are impossible.
Or rather he's claiming it's the 5-device-per-account limitation. That's a total non-issue since you can simply create another account. Again, might have a case with paid software where you'd need to pay a second time, but since VLC is free, there's no such limitation.
It's debatable if the app store licensing terms violate the GPL. I'd argue that they do not.
If memory serves, the (one) VLC developer claimed that it was because you were not free to distribute an iOS app, and that that violate the GPL. The GPL does not concern itself with the mechanism of distribution, only that the ability to do so exists.
You could probably successfully argue that a paid application cannot be distributed. However, I would argue that a free application can be. There is nothing stopping me (or wasn't, before it was pulled) from distributing the app by giving you the iTunes URL that will allow you to retrieve a copy. I can distribute a copy to you through this means. It doesn't matter how it mechanically happens, all that matters is that I want to get you a copy of the software, and I provide the means to do so.
As such, any GPL'd app should be perfectly fine on the app store so long as it is free, and providing that it follows the requirements for offers of source.
The thing is that Apple is going to play it safe; they're not going to fight the copyright infringement notification for the app developer. It's up to the iOS VLC developers to dispute the claim. This Rémi character is just a zealot.
Slashdot Mirror
Obsidian glass blades are far sharper than steel blades, and are sometimes used for scalpels. Some cultures did make swords out of them.
You can see some pictures and video here:
http://www.engadget.com/2010/09/14/rock-band-3-pro-guitar-preview-the-guitarist-vs-the-guitar-her/
At the end of the clip, they play the Fender guitar through an amp. Sounds out of tune to me (being a real guitar, it needs tuning if you want to play it through an amp), but I could be mistaken.
They specifically show the thing being used with generic sequencer software:
http://www.fender.com/promos/2010/rockband3/theguitar.php
Reviews seem to indicate that pro mode for guitar with one of these things is a bit more analog than the whole notes-scrolling-down-screen thing, so you might be able to do more tricks than you'd think.
By whose definition? A FOSS h.264 encoder would still adhere to all four of GNU's freedoms. GNU does not state that you must be free to charge money for it, only that you must be free to run it, free to (re)distribute it, free to study/change it, and free to distribute your modified versions of it to others. Nowhere does it say that you must be free to charge money for it without having to pay someone else.
The GNU certainly states that you must not be required to pay to do any of these four things, but charging money is not one of these four things. The distribution is still unrestricted, and since you can't use FOSS software in a non-FOSS commercial work, the freedom to distribute that commercial work with the h.264 encoder is unaffected.
It seems you're partially right. Harmonix is claiming that they only currently support one MIDI guitar (the Squier), but there doesn't seem to be any reason why the story should be different for any other MIDI guitar. Regardless, the Squier costs half as much as any other MIDI guitar, and will offer a far more realistic gameplay experience than the YouRock device, since the YouRock lacks real strings (somewhat important for a guitar).
Link to what? NX? http://en.wikipedia.org/wiki/NX_technology WiFi? http://en.wikipedia.org/wiki/Wi-Fi Thin clients? http://en.wikipedia.org/wiki/Thin_client
You can toss together a solution for $200-300 per unit (not including server cost) by throwing a generic Linux distro with NX installed onto an embedded PC and be done with it. It's pretty trivial and common place stuff...
*woosh*
Not only did you not read correctly, you missed the point. The "proprietary" label was not applied to MP3 or AAC, but "other proprietary formats". WMA might be an example. And the point wasn't that it was more or less proprietary, but that MP3 had been largely supplanted by newer codecs.
It's 150MHz wide, so three. That's not really an issue in home use (other than that it'll blow out any 802.11n networks trying to use that spectrum), but makes it useless for public use.
At that point, the crazy bandwidth/spectrum use is a bigger problem than the costs of solving it. Perceptually lossless video compression could get that down to 5% of the bandwidth used (I challenge anybody to tell the difference between 150Mbps 1080p60 video and uncompressed video) if you need fullscreen video, and remote desktop solutions (particularly those like NX that send text as text) are much better if all you need is some sort of status display.
In 40MHz of 802.11n space, I could take thirty nx-based thin clients that are small enough to mount on the rear of a monitor and still have plenty of bandwidth left over.
Any wifi thin client should do, since they don't rely on whole-frame video compression. It's a lot more optimal to send text *as* text (as many remote desktop solutions like X or NX do) than to send a video of the text. You'll get more than 30m of range (or rather, with a higher base range, given the same amount of interference, it'll go farther than WHDI), and you can have a lot more active clients than WHDI, which can only support three clients (40MHz channels in a 150MHz band) at a time.
No, there are exactly the same chances of being sued for implementing it: zero. The chances are also zero if you free distribute a FOSS encoder. You only need a license to *sell* an h.264 encoder.
The fact that you can only fit three full 40Mhz channels in the unlicensed 5GHz space, and that the range of this stuff is optimally 30m, means that it will be completely useless for what you describe. There are existing wireless display technologies that are enormously more effective for that sort of thing.
Pixel response times are not the same thing as input latency. IPS panels seem to be worse in this regard. There were a few relatively recent high-end Dell monitors that had multiple frames worth of latency.
Latency on wireless mice hasn't been an issue since the Fast RF was introduced in 2002. Your desktop LCD panel probably has far more latency than a good Fast RF mouse.
WHDI only uses a single 40MHz channel to do 1080p60. How they achieve spectral efficiencies that high is beyond me, but that's what their spec says.
True. I'll admit that I relied on the stated goals of each generation of codec rather than actual benchmarks. I'd note that the claimed efficiency improvement for Samsung+BBC is 40%, rather than 20-30%. This also obviously doesn't take encoder improvements into effect, as x264 is pretty advanced in thsi regard.
This doesn't really change my overall point, though. If MPEG-4 AVC achieves 2x the efficiency of MPEG-2, and Samsung+BBC is (let's split the difference) 1.3x as efficient as AVC, then we're currently 2.6x the efficiency of MPEG-2. This reinforces the point that there's room for improvement left.
Even if nobody is ever sued for VP8, and it turns out to be patent free in effect, that doesn't change the fact that there are major issues with it. All the patent-avoidance necessitated a rather steep decrease in efficiency (since most techniques that could improve efficiency are patented, unfortunately), and the VP8 spec is still rather buggy.
Google's biggest mistake was not bothering to write a proper spec, making the encoder the spec. The problem we're saddled with now is that the encoder is always behaving per-spec since it *is* the spec. Bugs in the encoder can't be fixed, and Google has already rejected valid bug fixes for the decoder because the encoder's broken behaviour is per-spec.
h.264 can't do VHS quality at 50Kbps, especially not if you include audio.
I might agree with 150-200Kbps, but even that's going to have to use special low-bitrate audio codecs like HE-AAC where the upper frequencies and stereo information is sort of faked. It was claimed that WMV9 (the basis for VC-1, which is closer to MPEG-4 ASP than h.264) claimed they could do VHS-quality at 250Kbps, and that was stretching the truth a bit.
As to get back to your original question, "You think there's a codec more advanced than MPEG4-derived 264?", the successor to h.264, HEVC, is targeting a doubling in efficiency, and is scheduled to be finalized by 2012. Doubling of efficiency would mean that the same quality is achieved with half the bitrate.
As was pointed out in other comments, nyquist/shannon have nothing at all to do with perceptual video compression. We'll reach a point some day when throwing more computational power and newer algorithms at the problem won't make much difference, but we're *VERY* far from that point today. There's a huge amount of room for improvement. The fact that we're still doubling efficiency with every codec generation (MPEG-2 -> MPEG-4 ASP -> MPEG-4 AVC -> HEVC each doubled efficiency) should be proof enough of that.
MP3 is popular for home use, but is virtually unused in terms of commercial use relative to AAC and other proprietary formats. JPEG remains popular because it reached the point where it was "good enough", with later competing codecs not offering a sufficient advantage to justify the pain of trying to move everybody to a new format. MPEG-2's video codec is still used in DVDs, and is *supported* by bluray, but BluRays encoded with MPEG-2 is extremely rare (pretty much everything is h.264 or VC1, mostly h.264).
Audio and still-image compression is not a field where large gains can be had so easily. If I produce a still-image codec that is 25% more efficient, then maybe I can save 5300 images on my SD card instead of 4000... but that's not going to make much difference. Same in terms of audio; I don't really care if my MP3 player can store 388 hours of audio or 517 hours. Audio has reached the point where we tend to encode everything at the same bitrate regardless of compression efficiency. In fact, uncompressed digital audio isn't exactly rare. CDs aren't compressed, and increasingly movies ship with lossless audio. We've reached a cap in terms of audio quality (more data doesn't help), but storage capacities keep going up.
Video, on the other hand, is a big deal. In terms of streaming, the amount of bandwidth required to compress good quality 1080p video still exceeds the connection speed of most broadband connections in north America (let alone disc-quality). On top of that, there's an increasing trend towards bandwidth caps.
Bell Canada in Ontario has a 25GB cap on usage. If we assume 5Mbps video (enough for 720p, at least), a consumer can only afford to watch about 23 minutes of video per day. If you double the compression efficiency (as the successor to h.264 aims to do), that becomes a *very* big deal. You can afford to stream much higher quality video to those with limited connection speeds, or stream a lot more video to those with limited transfer caps, or store more content on a disc. The impact would be felt enormously almost anywhere video is used.
Getting back to replacing h.264, let's examine a bit about how long it took h.264 to become ubiquitous. It's mostly replaced previous codecs, as it's now the dominant codec for consumer consumption. Your cellphone and video camera record to it, your disc-based movies use it, increasingly your television service uses it, your streaming video uses it, etc. h.264 was standardized in 2003. 7 years later, it's unquestionably the dominant standard. This was even true a year or two ago, so we might stretch this a bit and say that 5 years was enough for h.264 to go mainstream.
h.264's sucessor, HVEC, is scheduled to be finalized in 2012, with a targeted improvement over h.264 of 100% (same quality at 50% bitrate) By 2020, 8 years will have passed since "h.265" was standardized. At that point, I would fully expect it to be the dominant codec in use.
Google's motivation is obviously to try to establish an open source, free (as in speech) codec as the web standard for video.
Then Google picked the wrong codec to buy/push. WebM is likely to be just as patent-encumbered as h.264, since large parts of the VP8 spec were poorly ripped from h.264's spec, or are at least similar enough to be covered by many of the same patents.
A good examination on a technical level (including some thoughts on the likeliness of patent-encumbrance) can be seen here. He's admittedly a tad biased by being one of x264's lead developers, but he's also one of the authors of ffvp8, and it's an interesting read.
Of particular worry is the flawed nature of the VP8 spec; the reference implementation *is* the spec, bugs and all. Google didn't allow for any time to try to correct/improve the spec before declaring it final, so now we're all stuck with .
Sad news for the web, that we'll be saddled with outdated inefficient codecs that, at least in the case of WebM, are probably just as patent-encumbered as h.264.
By 2020, it's likely that we'll be using h.264's successor rather than h.264 itself.
Or, for $280, you can buy a Squire Stratocaster Guitar for RB3.
http://www.fender.com/promos/2010/rockband3/index.php
It's a proper electric guitar, with a phono jack for plugging into an amp, but it can also be used as an RB3 controller via the official MIDI adapter.
Of course, the same is true of *any* cheap MIDI electric guitar, but this thing costs half as much as the cheapest MIDI guitars, and has some game-related buttons on it too that get properly mapped via the guitar->MIDI->RB3 chain.
Precedents usually have to come from the same country...
IANAL. We don't have mass lawsuits in Canada like they do in the US. This isn't to say that the CRIA didn't try, but when they experimentally sued their first 29 filesharers in 2004, the judge (who incidentally is now chairperson of our telecoms regulator, the CRTC) ruled against their request for disclosure of the identities of the alleged fileshares. The cases then obviously were dead in the water, and I don't believe any have been filed since.
If you're interested in the reasons why the judge rejected the CRIA's request, the reasons why the request violated the rules established for such disclosures were:
1) The CRIA had hired a third party company, MediaSentry, to do the investigations, and the affadavit alleging evidence of infringement was signed by the president of this company, rather than the employees who did the investigation. As such, alleged evidence was hearsay, and not admissible.
2) MediaSentry had employed decoy music files, but did not verify that the alleged infringers had downloaded the actual songs in question and not the decoys, which they weren't being sued for. As such, no evidence was provided that the files in question were even the plaintiff's infringed files.
3) The CRIA alleged that the infringement was performed by various Kazaa usernames, but provided no evidence as to how they associated these usernames to the IPs for which they were seeking discovery. As such, there is no evidence that the IP was involved in the infringement.
4) The copyright act states that reproduction of an audio recording for private use by the copier does not constitute copyright infringement, and so the alleged downloading of the MP3 files did not constitute copyright infringement
5) No evidence was provided that the alleged infringers had distributed or authorized the reproduction of the files, merely that they had placed personal copies in a location that was accessible to others, and this does not constitute copyright infringement. Others accessing the accessible files is not copyright infringement, the user must take a positive act of sending the files themselves.
6) The CRIA alleged secondary infringement, but didn't even try to establish knowledge on the part of the defendants
7) The lawsuits were filed long after the infringement was alleged to have taken place (about a year), and retrieving the information requested (contact info of the person using the IP at the time) over such a long period of time was not practical or reasonable, and quite likely not even possible. Furthermore, the contact info of the account holder that owned the IP is not necessarily the same as the person who committed the infringement on the computer.
8) The great length of time between the alleged infringement and the filing of the lawsuit causes privacy concerns to outweigh the copyrights of the plaintiffs, since they gave no reason as to why they waited so long. I think the idea here was that clearly the damage caused wasn't terribly important since they waited so long.
The ruling in the end denies the CRIA's motion, and granted costs to the ISPs who participated. So the CRIA's attempt to try mass lawsuits US-style imploded in a spectacular manner. Without major changes to Canadian law, such lawsuits are impossible.
Or rather he's claiming it's the 5-device-per-account limitation. That's a total non-issue since you can simply create another account. Again, might have a case with paid software where you'd need to pay a second time, but since VLC is free, there's no such limitation.
It's debatable if the app store licensing terms violate the GPL. I'd argue that they do not.
If memory serves, the (one) VLC developer claimed that it was because you were not free to distribute an iOS app, and that that violate the GPL. The GPL does not concern itself with the mechanism of distribution, only that the ability to do so exists.
You could probably successfully argue that a paid application cannot be distributed. However, I would argue that a free application can be. There is nothing stopping me (or wasn't, before it was pulled) from distributing the app by giving you the iTunes URL that will allow you to retrieve a copy. I can distribute a copy to you through this means. It doesn't matter how it mechanically happens, all that matters is that I want to get you a copy of the software, and I provide the means to do so.
As such, any GPL'd app should be perfectly fine on the app store so long as it is free, and providing that it follows the requirements for offers of source.
The thing is that Apple is going to play it safe; they're not going to fight the copyright infringement notification for the app developer. It's up to the iOS VLC developers to dispute the claim. This Rémi character is just a zealot.