Live data from Hacker News

Forging an Alliance for Royalty-Free Video

blog.mozilla.org

21–30 of 61 posts

Re: Forging an Alliance for Royalty-Free Video

#21
post #18

Earlier quoted context omitted.

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…

Name one codec with specific support for DRM built into the compression.

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...

Re: Forging an Alliance for Royalty-Free Video

#22
post #13

I wonder what that means for Daala. It's scheduled to be finished by the end of this year. I hope it still gets finised.

I would guess, as an outsider, that it'll basically stop as an independent project and carry on to whatever degree its tech get absorbed into this new project.

There's lots of cool tech in Daala, but I'm guessing that most people involved would be happy to see a royalty-free video codec succeed even if it wasn't entirely their baby and if the member corporations can throw enough lawyers, engineers and existing patents at the problem, then less sexy, more traditional tech will probably get the job done and make Daala's strategy less relevant.

Re: Forging an Alliance for Royalty-Free Video

#24
post #18

Earlier quoted context omitted.

Name one codec with specific support for DRM built into the compression.

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.

Re: Forging an Alliance for Royalty-Free Video

#26
It will be interesting to see how much of the "stack" ends up being open and royalty free. Don't get me wrong, open format is great, but only part of the story.

That being said, I'm definitely optimistic this is a step in the right direction given the fact that Mozilla is a part of it.

EDIT: Actually, looks like they may be proposing full-stack will be open: http://aomedia.org/about-us/

Re: Forging an Alliance for Royalty-Free Video

#27
post #24

Earlier quoted context omitted.

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-invasiv…

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.

Re: Forging an Alliance for Royalty-Free Video

#29
post #5
post #2

This is great, but how does it compare to H.265/HEVC? And any news on hardware decoding support? IMO, hardware support is the thing that really makes a difference from a consumer experience point of view (more than patents). It's what allows one to watch hours of video without the device getting hot or losing too much battery life.

Getting your codec supported in hardware is a tricky business, and as much as I've been a huge fan of the Daala initiative it was always going to be an insurmountable hurdle for Mozilla alone. IMO getting buy-in from Cisco and Youtube actually gives us a fighting chance at an actual royalty-free hardware-supported codec, which is why I'm so excited at this news.

I'm sure Intel, one of the AOM partners, is interested in hardware codecs. :)

Re: Forging an Alliance for Royalty-Free Video

#30

Would be interesting to see if this can be pulled off mostly due to existing patents. H.265 license covers over 500 patents you can find quite a few of them dating form the 90's which will expire in 2-3 years, but also quite a few that wont. http://www.mpegla.com/main/programs/hevc/Documents/hevc-att1... Considering that many companies patent everything and their mother I wonder if it's possible to actually have a Ro…

This came up a few weeks ago.[1] MPEG-LA's patent portfolio isn't that strong any more. MPEG-LA has a long list of patents, but most of them have expired. The key patents on video compression involved motion estimation, and those expired this year. MPEG-LA got their twenty years of patent protection, and it's over.

The remaining patents are mostly on things you don't need for Internet video. US #6,181,712, has to do with multiplexing two unrelated video streams into one. Broadcasters and cable systems do this, but Internet video does not. US #6,160,849 only applies to compression of interlaced video, which nobody uses on line. US #7,627,041 is about dealing with missing header data due to transmission noise. US #5,878,080 is about backwards-compatible multichannel (>2 channels) audio, also seldom used on-line. US #6,185,539 is for video with overcompressed extra-low-quality audio. So is US #6,009,399.

As I pointed out last time, it's time for a hard look at this patent situation. You can probably do a patent-free MPEG-4 video decoder and encoder for Internet video now. You might have to leave out some newer features nobody uses.

[1] https://news.ycombinator.com/item?id=10042469 [2] http://scratchpad.wikia.com/wiki/MPEG_patent_lists

Post reply on HN