Includes non-free codecs in main package

[wjt]

The Blender Flatpak includes ffmpeg built with H.264 support (among other non-free codecs) which precludes it being installed by default in situations where no per-seat royalty can be paid (such as freely-downloadable and redistributable distro images). It would be great to see one of the following:

1. non-free codecs split into a separate extension (as @ramcq did for Pitivi https://github.com/flathub/org.pitivi.Pitivi/pull/7)
2. don't build non-free codecs, but use org.freedesktop.Platform.ffmpeg-full if present

[bochecha]

The problem with option 2 is that the ffmpeg provided by the platform might not be compatible with what Blender needs.

I keep hearing ffmpeg doesn't have a stable API, and I don't really want to spend my spare time figuring that out. :slightly_smiling_face:

I'd be fine with option 1.

However, that would mean building ffmpeg twice, once without and once with the problematic codecs, right?

[bochecha]

A second problem is that Blender doesn't look at what codecs are available: it just displays everything it knows of in the UI, and assume they are present. (at least that was the case back when I packaged 2.78, I didn't check recently if that still happens)

That leads to a pretty terrible UX where users try to encode the result as H264 and just get a confusing error. :slightly_frowning_face:

[ramcq]

The problem with option 2 is that the ffmpeg provided by the platform might not be compatible with what Blender needs.

I keep hearing ffmpeg doesn't have a stable API, and I don't really want to spend my spare time figuring that out.

This isn't as bad as it sounds these days - as in, ffmpeg has significantly calmed down and there has been I think one ABI change in a couple of years. Matching the runtime's ffmpeg is less likely to cause any real hardship.

I'd be fine with option 1.

However, that would mean building ffmpeg twice, once without and once with the problematic codecs, right?

Yes. Example https://github.com/flathub/org.pitivi.Pitivi/commit/621d1992 shows how you can add an in-app extension point. I'd test Blender against the platform ffmpeg before going down this avenue however.

A second problem is that Blender doesn't look at what codecs are available: it just displays everything it knows of in the UI, and assume they are present. (at least that was the case back when I packaged 2.78, I didn't check recently if that still happens)

That leads to a pretty terrible UX where users try to encode the result as H264 and just get a confusing error. slightly_frowning_face

A quick glance through looks like those format options are built up in code (ie, repeated calls to functions like add_format_thing ("H264", bla bla) so my gut feeling is you could probably wrap one of those in a call to dlsym to check if the H264 symbol was present in ffmpeg, and hide the option if not.

[bochecha]

I've started working on this. Work in progress at #43.

For now that just stops bundling ffmpeg, to instead use either the platform ffmpeg or the one from the ffmpeg-full extension if available.

I verified that the one from the extension gets used, but even then all I'm getting is "Unable to create encoder" and nothing else. (after spending half a day trying to figure out how to render things with that overly complex UI)

As for detecting at runtime which codecs are available, this code is in fact built as a tool which then generates the application code. It seems to generate the code for the UI options in a very generic way, so I have absolutely no idea how to make it do what we need.

[bochecha]

I figured out what the problem was with using the ffmpeg-full extension: it doesn't actually provide a full ffmpeg, it provides a full ffmpeg linked against the libopenh264 present in the openh264 extension.

Which means one extension depends on the other to work but I didn't have the latter installed.

With both extensions installed, Blender can correctly render an H264 video. With any of them uninstalled, it can't.

So that solves the issue of the bundled patented codecs in the app.

However it's a terrible UX to users who don't have the extensions installed, which is something I'd really like to fix, and at this point I have to give up because it's way past my C skills. :disappointed:

[ramcq]

That's a curious decision - why would ffmpeg-full not just use the bundled H.264 impl? Deferring to libopenh264 is more relevant to the royalty-free ffmpeg because it allows the H.264 download to be deferred.

[eszlari]

They enabled ffmpeg's native H.264 decoder, but not libx264 for encoding:

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/19.08/elements/extensions/ffmpeg-full/ffmpeg.bst

[bochecha]

They enabled ffmpeg's native H.264 decoder, but not libx264 for encoding:

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/blob/19.08/elements/extensions/ffmpeg-full/ffmpeg.bst

Yeah, we figured that out yesterday. ~I'm working on a fix.~

Unfortunately, using libx264 in ffmpeg-full means passing the --enable-gpl option, which then conflicts with the fdk-aac codec, requiring to pass the --enable-nonfree option.

Those options are IIUC to acknowledge that enabling those codecs puts ffmpeg in a murky licensing solution, and transitively the apps linking against it.

That's probably not a decision we should take in the runtime on behalf of the apps, so we're leaving it at that for now.