Hacker News Reader

Comment by rasz | Hacker News Reader

Someone was posting recently how it cost him tens of dollars of LLM Agent time to reverse engineer Linux Davinci and add codec he wanted back in.

View on HN

This is one of the the cases where “the language model won't necessarily respect IP law” is really relevant. Individual users may be able to get away with this because they're too scattershot to sue, and users in some jurisdictions may actually be fine regardless, but broadly, the patent licensing around things like H.264 is not something BMD can afford to ignore. AFAIK the biggest reason Google was pushing WebM in the first place was because they, a huge corporation, were balking at being under the thumb of the MPEG LA!

I appreciate that it can be confusing for users that patents can still apply to techniques where implementations exist that are both libre and gratis from a copyright perspective, but this has been an issue for Linux-adjacent software distribution for ages—like, see how Debian used to put certain stuff that was encumbered by patents in the US but not in other jurisdictions in special “non-US” repository sections, that sort of thing. It's not Black Magic's doing that the codec space is like this. I wish people wouldn't make so many mocking assumptions sometimes.

Linux Vivaldi builds use libffmpeg.so from chromium-ffmpeg, which includes decoders for most codecs used on the web (no h265/mpeg2 tho), and VA-API which will handle all hardware accelerated codecs on particular platform.

This looks similar to using Microsoft provided Media Foundation codecs. No idea why Black Magic doesnt do it like Linux Chromium browsers.

Do you have any information on how the actual patent licensing is set up for Vivaldi? I wasn't able to find much on it, though I see the note in https://wiki.archlinux.org/title/Vivaldi that it “automatically downloads” the relevant files, which is at least suggestive that they can't just redistribute the binaries normally. The other closest thing I was able to find was https://github.com/chromiumembedded/cef/issues/3559 which describes a specific proprietary_codecs option in CEF, which is not quite the same thing but ought in some sense to be related… the way they describe having to set ffmpeg_brand=Chrome normally for that to be available doesn't sound promising?

I would be moderately surprised if whatever arrangement is going on there allows full use of the codecs for video editing software and not just for consumer decode of Web resources.

I would suspect that since they leverage VA-API (and NVDEC/NVENC thu shim) all patent stuff is pushed on to hardware vendors?

That doesn't sound right to me at all. I'm pretty hazy on the specifics of VA-API, but I wasn't under the impression that the graphics hardware carries 100% of the decode implementation nor had codec licenses attached to it, and this Phoronix article from 2022 describing Fedora having to back off from having accidentally shipped H.264 via VA-API without appropriate licensing seems to be evidence in the direction I expected. https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API

Fedora is legally owned by Red Hat, Red Hat is owned by IBM, IBM loves patents and will always have most pro patent view possible.

If there were definitely no legal encumbrances, surely they'd want to keep shipping the version with the proprietary codecs in, because that would make them a superior option for users who need those? AFAICT someone upstream thought that having the toggle to avoid patent issues was important, which if true nixes the idea that VA-API just gives you an automatic unencumbered route and you don't have to worry about it after that.

I'm not really sure what actual claim you're making regarding the relevance of “pro-patent views”, but I might interpret it as something like “Red Hat is more likely to play it safe, whereas less IBM-enculturated distributions are more likely to bet on interpretations that let the users take on the risk”. Which I think is probably true; for instance, https://www.reddit.com/r/linux/comments/xqn20n/comment/iqbmv... describes how other distributions chose differently and moved to re-enable the proprietary codecs by default. (Some of them seem to be based in friendlier jurisdictions, mind. I'm not completely sure where BMD is, and I'm not sure how much it matters given they want to sell worldwide, but their full corporate name resolves most strongly to Australia: https://opengovau.com/business/30098098287 and Australia doesn't seem to exclude software from patentability: https://www.ipaustralia.gov.au/patents/what-are-patents/what...)

Anyway, if that's what you meant, I don't think that distinction is nearly as applicable to the situation with Resolve. BMD isn't a producer of a Linux distribution containing a broad variety of stuff, where “users happen to do stuff with the open source software we provide that violates some patents” can maybe be waved off as not their responsibility. BMD is very obviously directly operating in the commercially-distributed professional video tooling market, so codec licensing will be something they have to deal with as a keystone part of their business. Adding something to their software to actively enable people to do professional-style encoding for those codecs without the patent licenses would be playing with fire.

Reply on news.ycombinator.com