Well, DRM is completely independent from the codec. You can put DRM on a free codec and you can have a non-free codec without DRM. As for Hollywood... note that the Alliance also includes Netflix.
DRM has to be kinda an integral part of the Codec in order for it to work efficiently especially with streaming any other type of DRM will not be really viable since it will either require you to get the entire file or to chop the video into smaller blocks.
DRM for the most part is encryption and if you want to have it with all the vector voodoo of video compression it has to be built in.
That said today there is no way in hell to make a codec without DRM and expect it to have wide support, lack of DRM is actually killing more projects (like various open source streamers) than outrage of the free software community will ever be able too.
An open codec is only viable if it's worth to be picked by the big players and those are the big media and content providers who won't pick up a penny if it didn't had DRM support...
CSS, AACS and HDCP are all broken, Flash is on its last legs and music downloads have largely abandoned it to positive consequences. Streams seem to be the last bastion, but that doesn't even make sense -- the reason people subscribe to Netflix is to watch new content every month, not to watch the same content over and over. If they wanted to do that they would just buy the Blu-ray (or, if so inclined, pirate it once). And pirates have no reason to rip a 6Mbps stream when they can rip a 40Mbps Blu-ray.
DRM is a box you have to check when a suit was bamboozled by a DRM snake oil salesman into putting it in a contract. How the DRM works is irrelevant because it won't actually work anyway. A fig leaf doesn't need codec support.
That's what EME is about, and that's why you hear the free software people griping about it but not the actual pirates. EME makes piracy easier. It separates the DRM into its own little box which makes it easier to circumvent. Which is what the pirates will do because they don't care about breaking the law, but which law-abiding free software people are proscribed from doing by DMCA 1201.
But the most fundamental flaw in your argument is that you misunderstand who decides what DRM gets used. DRM is not content. What gets supported is ultimately decided by the platform companies. When Apple says there will be no DRM on iTunes, there will be no DRM on iTunes. The only thing Disney or Universal can do about it is withhold their content, but that costs them more than it costs Apple or Google. Which means it isn't something they can credibly threaten unless the dispute is of a make or break significance, and the particulars of DRM implementation are not on that level.
There aren't any, the DRM is tied to the 'container' and that's part of the standardization process here.
Everybody 'hates' DRM, it seems but I don't think it's going anywhere and I don't think you can ship a codec standard without it. You usually want hardware support for the DRM encryption. I don't know the specifics of their technology, but Netflix and Hulu and Amazon all stream tons and tons of media and I'd be surprised if it wasn't DRM'd in some capacity, I know the video apple sells/streams all is.
I'm not aware of any codec with DRM built in to the compression, but essentially every DRM scheme integrates decompression into the DRM module as closely and inseparably as they can manage. Royalty-free codecs make that quite a lot cheaper to do.
My understanding is that IPMP was not precisely builtin to MPEG-2 or -4. The fact that it could be backported to MPEG2 is partly indicative of this.
IPMP does not in any meaningful way alter the H.263 or H.264 compression algorithims, even though it does alter the bitstream in ways that require modifications of the encode/decode pipeline
There is nothing stopping a third-party from similarly making a pipeline-invasive DRM for any open codec. As a matter of fact, if the open codec is patent free, then there would be no legal way to stop them.
Both MPEG-2 and MPEG-4 have several revisions, while not being directly tied to the "compression" which might be the wrong choice of words IPMP hooks into virtually every step in the encoding and decoding pipeline.
You can implement multiple IP controls over every bit of the format from audio streams to the scene constructing language that is used to rebuild the scene it self so you can technically put DRM on individual elements so you can literally force people to pay money to see Kevin Spacey instead of a banana in house of cards without having to encode 2 completely different video streams into the file, but I'm pretty sure people will pay extra to see a banana instead of Kevin Spacey.
And while you can make a DRM free encoder it's still wasn't the argument that i was talking about if there won't be a well established and well integrated DRM mechanism within the design of the Codec it will be dead in the water since for a codec to be widely accepted these days it needs to be adopted by the media/movie/tv/streaming/content delivery whatcha gonna call it industry and that industry needs DRM.
Heck even sites like YouTube use DRM these days (paid content trough), Twitch and other similar sites will eventually have to enable DRM too if they want to offer premium content as it's much easier to gate people with DRM than to have some weird session based authorization for streaming which is a nightmare and doesn't really work as DRM.
And using multiple codecs (cie? x's? xes?) is probably not a viable approach either.
I still maintain that a good royalty-free codec will get a DRM standard (by a third party if the creators don't define one), so having it not builtin to the core standard is a non-issue.
