I finally decided to release Platinum, my UPnP SDK. It will be hosted by Sourceforge for now. It will have a dual license: GPL + Commercial. I have spent the last few days trying to clean it up a bit (mainly removing the Windows Media Connect and Xbox 360 hacks). In doing so, I realized that I really needed to rewrite it . The pull model I have used is not very bandwidth efficient. The reason is that I am running a bunch of “tasks” in a round robin way and sleeping in between tasks for 30 ms. So for example, the maximum throughput I am getting while transferring a file locally (from the UPnP Media Server using wget), is only 4 MB/s. The Intel MediaServer on the other hand can go up to 17MB/s. It’s not really a problem for now (as I have used Platinum to stream audio+video from a PC to a PSP wirelessly without a glitch) but it bugs me it’s so slow. Hopefully once gilles releases Mikado, I’ll switch to using that.
According to this research firm, DRM is here to stay. Sorry nick!
In response to Nick’s comment about DRM, I suggested that Movie Studios would be more likely to support a subscription service model, if they chose to not use DRM. Well it sounds like someone is sorta thinking along the same way as I have just read very interesting news about why the true video ipod is being delayed:
“According to ThinkSecret, the company (Apple) wants to stick with the iTunes model of selling individual flicks, while the studios are looking for a MusicNet-style subscription service.”
I agree but why choose MusicNet to refer to a subscription service when Rhapsody is #1?
OK I am biased … < grin >.
Finally someone was smart enough to realize that CNet experimentation as described in my previous post was completely flawed. Bravo Engadget for that!
I was really surprise last week when I read this CNET review. I usually don’t care much about attacks to DRM but I have to respond to this propaganda. If you’re going to attack DRM, at least make an effort to get your story straight. In the article, the author (James Kim?) goes on by saying that playing DRM tracks on your portable device will drain your battery 25% faster. Ok that’s fine, I can believe that..maybe. So I read the experiment they made. They went and compare DRM free mp3s with wma DRM tracks from Rhapsody (and Napster). Ok how about comparing apples and oranges!
Everyone that has a little bit of technology background would know that codecs have different CPU requirements which means they have different battery requirements. To really prove the point, you would have to compare a DRM free wma with a DRM wma AT THE SAME BITRATE and then you’d have a better comparaison. Talking about bitrate, I know as a matter of fact that Rhapsody subscription tracks are encoded @ 160 kbps (at least they were when I was there). So you can’t compare them with 128 kbps MP3s. Note that the article doesn’t mention any bitrates.
Another absurd quote from the article: “Those who belong to subscription services such as Napster or Rhapsody have it worse. Music rented from these services arrive in the WMA DRM 10 format, and it takes extra processing power to ensure that the licenses making the tracks work are still valid and match up to the device itself.”
Ok, first of all, checking that a license is still valid doesn’t require any work, mr smart ass. What requires more processing power is the actual decryption of the content. The crypto part used in content decryption is a lot more expensive than the license validation. At least, it should be in a properly designed DRM :-). The license describes what the device can do with the content, there’s really no need to encrypt it. However it needs to be signed to ensure integrity (meaning to ensure that nobody modified it). In any case, verifying a signature is a lot faster than decrypting the content. Even though Asymetric encryption is used for signatures, the verification (decryption) is always fast because decrypting with a Public key is always faster then decrypting with a Private Key (since it’s smaller). Symetric encryption (and decryption) is however faster than Asymetric encryption (and decryption) which is why content is usually always encrypted with a symetric algorightm (like AES-CBC or the old 3DES). But, since only the hash of the license (160 bits) is being signed and not the entire license, and generating a hash (SHA1) is very fast, it just doesn’t matter compare to decrypting MBytes of content. You see now why decrypting content is always going to take more CPU (thus power consumption).
Now, of course DRM is annoying. Damn I hate it. However, I think I am better off because I accept the fact that there is no way around it. DRM will always exist. You think IPTV will be all free and clear? You think Cable will deliver unscrambled feeds to everyone and trust you to not “tune” in for free? Come one, get real people.
Now, what my job is, working for a DRM company, is to create a DRM that is as transparent to a user, as flexible as possible to create new business opportunites and as easy to implement as possible. I believe a DRM system should be opened and standardized just like Cryptographic algorithms are. Because, in the case of Crypto, the robustness is in the key not in the algorithm. Same thing goes for DRM.
When a user will be able to move content from a device made by Manufacturer A to a device made by Manufacturer B without thinking why it couldn’t be done, then I’ll know I’ve achieved my goal. We’re note quite there yet but I know we’re not far…stay tuned.
Today I decided to fix my Blog comment spam problem. For every post I would do, I’d get at least 2 to 3 comment spams. It sucks as there are some legitimate comments (for example nick’s). So I found the remedy: Akismet. We’ll find out soon if this really works …