Comment by xinayder
21 hours ago
They'd rather add agentic AI support instead of adding proper codec support on the free Linux version (which is already supported on Windows).
smh
21 hours ago
They'd rather add agentic AI support instead of adding proper codec support on the free Linux version (which is already supported on Windows).
smh
It’s because those codecs require SDK’s that are expensive to license. That’s not a Linux specific issue - it’s always been that way for the non-studio version of Resolve (with some exceptions on MacOS since the ProRes codecs are already part of the OS).
How come most mainstream distros have support for said codec but Blackmagic cannot/won't add support for it on Linux?
Why can Openshot, Kdenlive, any other Linux-native video editor edit MP4 files but DaVinci cannot, unless you pay for it?
Genuine question.
There are a couple of things going on here.
Primarily because Resolve is meant as a tool for professionals - and as a result it can’t get away with using things like Ffmpeg under the hood.
Ffmpeg (for example) doesn’t use officially licensed codec SDK’s to handle certain codecs - it uses reverse engineered tooling.
If you’re working on a personal project or something that is just getting pushed to YouTube that won’t matter 99% of the time.
However if you are working on a professional color grading pipeline for a project that might go to broadcast or into theaters, there are very specific QA tests that the final rendered product must pass - and these unofficial reverse engineered rendering tools often result in rendering errors that can fail these QA tests (and in a way that is basically impossible to troubleshoot).
It’s already enough of a challenge to manage a color pipeline using the officially licensed tools - they can’t really risk that kind of issue with their pro and semi-pro customers.
That said, it’s important to note that MP4 is a just a container/wrapper, not a codec.
So an mp4 file might contain video (or just audio) that is rendered using one of many possible codecs depending on what was chosen by the person doing the render. That will determine whether Resolve whether the free edition of Resolve will support it or not.
Is it surprising that they’d rather make features that cater to a large portion of their user base instead of a tiny fraction of it?
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.
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.
Haha yeah was about to post this very comment. I'm glad to see they have their priorities in order instead of checks notes supporting MP4 on Linux, the most common type of goddamn encoding. GoPro footage literally does not work with Resolve outside Windows.