Firstly, I think the skeptics answer pretty much covers it: DRM annoys people. Some of us actively avoid purchasing anything with it.
In terms of software, this is pretty much impossible. One DRM scheme might be to use public key encryption with content encrypted with symmetric keys (performance of symmetric ciphers being vastly superior to most pk ones). You encrypt the content key with the private key and the software can then decrypt that key with the public key, and decrypt the content.
Which works, except that I'm just going to step your program through a debugger or disassemble your code until I find your key, decrypt your content and the game's up. Crypto is for transmission over insecure networks, not for decrypting securely and in isolation on hostile systems.
So, you could send lots of different keys over the internet for different parts of the content. Well, your paying customers are likely to experience problems with this, but, I can just automate the debugging process, or hook your receive events, or whatever. Either way, I can grab those keys. It isn't easy, but it can be done.
So the next stage is to prevent me using my debugger or hooking your system calls in some way, which is where you start writing rootkits. As it happens, I can take the disk offline and examine/disable your rootkit, or modify it so your software believes it is secure. In fact, this will make it easier for me to identify what you're protecting.
There is another case, one where the OS is complicit and provides some form of secure container. If it is possible for me to load code into ring 0, this security becomes irrelevant. If not, if I can clone your microkernel core and modify it to allow me to load code into ring 0, this security becomes irrelevant again.
At this point you have to start using hardware controls. Simply put, since I can modify the operating system any way I please, you probably need hardware-implemented DRM that I have no chance of modifying or reading. You'd need your crypto to happen on-hardware such that it is impossible to read the decrypted data from the operating system. You'd need the public key I mentioned above to reside on that hardware, not on the OS.
At this point, you've probably defeated me personally, but I am sure there are people capable of modifying their HDMI cables (or whatever) to split the data out onto the display and to another device such as storage.
Also, how you store your keys securely on your device is going to be an issue. You'd need to encrypt them! Otherwise, I'm just going to attach your storage device to an offline system. And store the keys... wait... see the pattern?
Once you have physical access, the game is up.
I don't think DRM is technically possible. Whatever methods you employ, there will always be someone with sufficient skill to undo it, since at some level that protected content must be decrypted for their viewing. Whether they have the motivation to is another matter.
From a software engineering perspective, getting it right, whilst not disrupting your users, allowing them to easily move their content to authorised devices, supporting new devices... all nightmares. Who's going to buy your content, when you haven't got Windows 8 support ready for launch? Does your content work on my Windows XP box too? What do you mean you don't support it?! If you use hardware, you have a deployment issue.
Finally, DRM is just deeply unpopular.