SUMMARY Digikam 7.7.0 has completely failed to build from source against all architectures supported by Ubuntu when built against libavcodec59. Apparently the compiler in both Ubuntu and Debian has been spitting-out compiler deprication warnings with previous ffmpeg releases for some time now. From the logs: /<<PKGBUILDDIR>>/core/libs/threadimageio/video/videodecoder_p.cpp: In member function ‘bool Digikam::VideoDecoder::Private::initializeVideo()’: /<<PKGBUILDDIR>>/core/libs/threadimageio/video/videodecoder_p.cpp:93:49: error: invalid conversion from ‘const AVCodec*’ to ‘AVCodec*’ [-fpermissive] 93 | pVideoCodec = avcodec_find_decoder(pVideoCodecParameters->codec_id); | ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | const AVCodec* make[3]: *** [core/libs/threadimageio/CMakeFiles/core_threadimageio_obj.dir/build.make:443: core/libs/threadimageio/CMakeFiles/core_threadimageio_obj.dir/video/videodecoder_p.cpp.o] Error 1 make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu' STEPS TO REPRODUCE 1. Attempt to build binary package using source package in Ubuntu's launchpad infrastructure OBSERVED RESULT All binary packages in all architectures fail to build. EXPECTED RESULT All binary packages in all architectures build. SOFTWARE/OS VERSIONS Linux: Ubuntu 22.10 ADDITIONAL INFORMATION amd64 log: https://launchpad.net/ubuntu/+source/digikam/4:7.7.0-2ubuntu2/+build/24183396 Other build logs available at https://launchpad.net/ubuntu/+source/digikam/4:7.7.0-2ubuntu2
Hi, digiKam 7.X ==> ffmpeg 4.x LTS only digiKam 8.x ==> ffmpeg 4.x or 5.x (code compile with ffmpeg 5.x but it not yet suitable for production). The transition between ffmpeg 4 to 5 is complex and not documented. API is at some place completely different or dropped. So for me migrating to ffmpeg 5 is very problematic for all applications depending of this framework and it's very dangerous to make a fast transition. From a developer viewpoint, FFMpeg 4.x LTS is robust and work very well. I recommend to not switch to ffmpeg 5 in production for the moment. Gilles Caulier
(In reply to caulier.gilles from comment #1) > From a developer viewpoint, FFMpeg 4.x LTS is robust and work very well. I > recommend to not switch to ffmpeg 5 in production for the moment. Well, we don't really have much choice. Debian, and therefore Ubuntu, is moving to ffmpeg 5. So, this is a distribution-level decision and not one that can be overridden.
(In reply to caulier.gilles from comment #1) > digiKam 8.x ==> ffmpeg 4.x or 5.x (code compile with ffmpeg 5.x but it not > yet suitable for production). If you have at any point a pre-release for digiKam 8.x, please advise. As it stands currently, 7.7.0 cannot be released in Ubuntu 22.10 in October. Feature Freeze comes end of August, at which point it's likely we'll have to eject digiKam from the repository for the FTBFS issue unless we can get that resolved via a patch. I'm the leader of the Ubuntu Studio flavor, and digiKam is our premiere photo management application. I really don't want to lose it, so I'm trying to find solutions to this issue sooner rather than later.
Hi Erich, The solution for you is to use 7.x as well. If ffmpeg 5.x is present, the Media Player support will be disabled at configuration time. Of course you will not able to play with video files (aka thumbnails and preview will be unavailable). For 8.x, the plan is to release before end of this year and if projects advance well, to include the both GoSC 2022 tasks in this release. We will see. https://community.kde.org/GSoC/2022/Ideas#digiKam 8.x will be also compatible with Qt 6, but i do not recommend to use Qt6 for the moment. 8.x will be compatible with Qt5 LTS, so this version rock well. About the 8.x pending list bugs, we have the famous Media Player code to finalize with ffmpeg 5.x, and other regression checks to verify. For ex, we will progressively switch metadata write operations to ExifTool instead Exiv2, as this last library break regression tests more and more. ExifTool write feature have been introduced in 8.x only. We need to check performances and suitability. Don't forget the bundles that we provide, as AppImage which still compiled with ffmpeg 4.x. There are 2 versions: one build by the team, other one build with KDE infrastructure. The first one is provided since a very long time and is very powerful and complete. It's based on 7.x code. https://files.kde.org/digikam/ The second one need to be finalized as it do not support Mysql/mariadb database. It based on 8.x code. Some links: https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/ Best Gilles Caulier
(In reply to caulier.gilles from comment #4) > Hi Erich, > > The solution for you is to use 7.x as well. If ffmpeg 5.x is present, the > Media Player support will be disabled at configuration time. Of course you > will not able to play with video files (aka thumbnails and preview will be > unavailable). In our packaging we simply had forced it with "DENABLE_MEDIAPLAYER=ON" in our debian/rules file, and removing that enabled it to build in my PPA. I'm working with one of our more senior Ubuntu developers to see if we should proceed with that route, or if he wants to do a manual patch to port it over to ffmpeg5 as he has more experience with that than I do. > For 8.x, the plan is to release before end of this year and if projects > advance well, to include the both GoSC 2022 tasks in this release. We will > see. > > https://community.kde.org/GSoC/2022/Ideas#digiKam > That will likely not make it in time for 22.10, but will likely make it for 23.04 in April 2023. > 8.x will be also compatible with Qt 6, but i do not recommend to use Qt6 for > the moment. 8.x will be compatible with Qt5 LTS, so this version rock well. I don't foresee the transition to Qt6 for some time. > About the 8.x pending list bugs, we have the famous Media Player code to > finalize with ffmpeg 5.x, and other regression checks to verify. For ex, we > will progressively switch metadata write operations to ExifTool instead > Exiv2, as this last library break regression tests more and more. ExifTool > write feature have been introduced in 8.x only. We need to check > performances and suitability. > > Don't forget the bundles that we provide, as AppImage which still compiled > with ffmpeg 4.x. There are 2 versions: one build by the team, other one > build with KDE infrastructure. Appimages cannot be packaged in Ubuntu under any circumstances.. However, there is a snap which, if a couple of things were tweaked, could be seeded. However, I think we might have a solution with the .deb package whether it's the port or the mediaplayer disable. > The first one is provided since a very long time and is very powerful and > complete. It's based on 7.x code. > > https://files.kde.org/digikam/ > > The second one need to be finalized as it do not support Mysql/mariadb > database. It based on 8.x code. Some links: > > https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage- > centos7/ Remember, I'm coming at this from a packaging/distribution perspective, so I'm looking for pre-release code as opposed to pre-release compiled/executable code. If we can get it in to the repository prior to our Feature Freeze, then that negates the need for a Feature Freeze Exception when a digiKam final release would come later as it would be considered a bugfix. Thanks for your time, Gilles. I really appreciate it. If you have any other info, that would be helpful. Erich
Hi Erich, >In our packaging we simply had forced it with "DENABLE_MEDIAPLAYER=ON" in our debian/rules file, and removing that enabled it to build in my >PPA. I'm working with one of our more senior Ubuntu developers to see if we should proceed with that route, or if he wants to do a manual patch >to port it over to ffmpeg5 as he has more experience with that than I do. Thanks to your proposal for porting help to ffmpeg5. In all cases, ffmpeg 5 must be done in 8.x. See below the reasons why: 1/ 7.x use a maintenance branch named qt5-maintenance where no new main features will be add. 2/ 7.x Media Player feature depend of QtAv external dependency. QtAv use ffmpeg API. 3/ QtAv is not maintained since February 2022. 4/ In 8.x we include QtAv in digiKam core and we apply a lots of patch to port Qt6, ffmpeg5, and fix plenty of bugs. 5/ ffmpeg 5 port must be done in QtAV code includes in 8.x, as 85% of the job is already done. The QtAV code in located here in digiKam 8.x (master branch) : https://invent.kde.org/graphics/digikam/-/tree/master/core/libs/video/qtav Look well the TODO list from the REDAME file. There is an entry in bugzilla where we list the QtAV integration progress and the identified problem with the ffmpeg 5 API : https://bugs.kde.org/show_bug.cgi?id=448681 Look the comment #33. The main problems are AVCodecParameters and AVCodecContext in QtAV code which are not properly ported to ffmpeg 5. The side effect is a quickly freeze of media player when a video is read. We will really appreciate all contributions to finalize the ffmpeg 5 port. Please use the Gitlab Merge Request workflow to contribute to digiKam source code. https://invent.kde.org/graphics/digikam/-/merge_requests Thanks in advance Gilles Caulier
We decided a way forward is that we're going to have to package git snapshots while we wait for official beta or final releases. Let me know if you would like some testing done in the meantime, I'd be more than happy to help with that. :)
Hi Maik, We need to decide if 7.8.0 will be the last version of 7.x serie or not. I vote for no, as the i18n diverge more and more compared to master. If we would to maintain 7.x later 7.8.0, we need to ask a i18n branching by translator teams. I think master code is ready to be published as beta, even if ffmpeg 5 is not yet finalized (ffmpeg 4 support work like a charm). We can release 7.8.0 in September for ex. Gilles
Yes, I also think that we should provide one more version as a service release. I don't think the translation team wants to maintain two digiKam translations. Maik
Our problem in both Debian Unstable (sid) and Ubuntu Kinetic Kudu (Future 22.10, due in October) is that ffmpeg 4 simply no longer exists, therefore 7.8.0 is a no-go for us. Therefore, we must use the master code for 8.0.0, even if incomplete.
Again, the decision to drop ffmpeg 4.x always maintained in favor to not mature yet ffmpeg 5 is typically dangerous. Not all clients code using ffmpeg API will not immediately switch to new API and perform regression cases. Gilles Caulier
(In reply to caulier.gilles from comment #11) > Again, the decision to drop ffmpeg 4.x always maintained in favor to not > mature yet ffmpeg 5 is typically dangerous. Not all clients code using > ffmpeg API will not immediately switch to new API and perform regression > cases. > > Gilles Caulier Of course, but I'm on the receiving end of this as much as you are. I'm a mere packager and had no input in the decision to drop ffmpeg 4 in favor of ffmpeg 5. However, what's done is done, and this is what I have to work with. Erich