![]() ![]() It seems that we've come to a rough consensus here to follow the lead of SUSE and Red Hat here. 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. I'm not a format expert nor am I a international patent lawyer, so I can not do this research on my own. 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. 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.Known issues that will need to be resolved 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). The MLT part of !1323 (merged) depends on FFMpeg's (4.x+) libavformat for decoding.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. Right now, the main way that Krita communicates with FFmpeg is through running CLI commands via QProcess in KisFFMpegWrapper, which is kind of awkward.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. 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. ![]() Right now, we require users to bring their own FFMpeg, meaning that core animation functionality is missing "out of the box".What's the problem with the way we're currently doing things? We will need FFMpeg (specifically libavformat) in order to merge the KisPlaybackEngineMLT part of !1323 (merged), with improved synchronization and reliability.We need FFMpeg to allow users to export their session recordings captured with the Recorder Docker.We need FFMpeg to allow users to import a video as an animation.This is a must-have feature for animation. We need FFMpeg to allow users to export their animations as video files.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. Hey all, I'd like us to have a group discussion around FFMpeg. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |