Let's talk about... FFMpeg!?

Hey all, I'd like us to have a group discussion around FFMpeg. @eoinoneill and I both figure that it's easier to have that discussion by separating it from all the other stuff that's going on in !1323 (merged), so I've decided to break this into it's own merge request.

Why do we need FFMpeg?

• We need FFMpeg to allow users to export their animations as video files. This is a must-have feature for animation.
• We need FFMpeg to allow users to import a video as an animation.
• We need FFMpeg to allow users to export their session recordings captured with the Recorder Docker.
• We will need FFMpeg (specifically libavformat) in order to merge the KisPlaybackEngineMLT part of !1323 (merged), with improved synchronization and reliability.

What's the problem with the way we're currently doing things?

• Right now, we require users to bring their own FFMpeg, meaning that core animation functionality is missing "out of the box". This has been made more user-friendly in recent years thanks to KisFFMpegWrapper::findProcessPath and is relatively painless on Linux, but for less technical users this still creates an extra hurdle. We've had a lot of requests in the past to streamline this whole thing, and in an environment where users are becoming increasingly used to isolated apps I think we should expect more.
• Right now, the main way that Krita communicates with FFmpeg is through running CLI commands via QProcess in KisFFMpegWrapper, which is kind of awkward. Adding FFMpeg (specifically libavformat, the part that handles encoding and decoding of formats) won't fix that over night, but it might give us a path towards cleaning some of that stuff up.
• The MLT part of !1323 (merged) depends on FFMpeg's (4.x+) libavformat for decoding. At this risk of pushing a sunk-cost fallacy, without libavformat we will not be able to merge the KisPlaybackEngineMLT part of that patch and will have to do our best within the limitations of the KisPlaybackEngineQT (More or less the old animation driver, using QtMultimedia for audio).

Known issues that will need to be resolved

• We need to put our heads together to come up with a list of codecs that we believe to the best of our ability to be non-problematic in terms of patents and licenses. Our collective intent is to follow all laws, respect all patents, and to do this properly so that we can make things better for users. I'm not a format expert nor am I a international patent lawyer, so I can not do this research on my own. If you have any knowledge, questions or concerns about potential problems around a specific codec that is being discussed for inclusion, please speak up and we will remove it from consideration. It seems that we've come to a rough consensus here to follow the lead of SUSE and Red Hat here. If anybody has further concerns about specific codecs from a legal or patent standpoint, please make them known and we will not include them.
• @lsegovia has pointed out that FFMpeg's build system will not work on Windows without MSYS2, and has suggested instead to use or make a wrapper. We're now using a Meson wrapper from the GStreamer project.

Other things to consider

• Krita's existing KisFFMpegWrapper, as it works now, requires the ffmpeg binary executable and not just libavformat. - Because we will have to ship a subset of common formats, I expect that some users will still want the option of providing their own ffmpeg. Should we design around this assumption in the future or should we stick to only the free, non-problematic formats that we can bundle and suggest that users convert outside of Krita? I think the consensus here is that in the long term we should continue to provide users with the option of supplying their own external ffmpeg if possible, keeping KisFFMPegWrapper around and building on top of that should make that relatively painless in most cases I think.

I'll wrap this up by saying that the conversation around codecs and software patents is a minefield of practically unknowable questions that we (especially as a bunch of non-lawyer programmers) have very little hope to be able to answer properly. Navigating that can be frustrating to say the least... But if we can come together as a community with the shared intent to do things right and adhere to patents by taking a "conservative" approach and simply avoiding anything that there is any reasonable doubt about, then I think we can do this properly.