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.

MPEG4 trough part 13 (IPMP was also backported into MPEG2) http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_...

http://www.w3.org/2000/12/drm-ws/pp/koenen.pdf

H.264 (trough IPMP), H.265 also implement in-bistream DRM interfaces directly into the decoder...

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.