TiGR
commented
3 years ago @alemariusnexus Well... The reason I worked on kffmpegthumbnailer is that libffmpegthumbnailer has an interface to generate metadata-based thumbnails and that's what I use the most. ffmpegthumbs has no such option and I am not good at c++ enough to do the work. That's why there is a reason for kffmpegthumbnailer existence, unless someone ports all its features to kffmpegthumbs. So, if ffmpeghtumbs were feature-complete fork of ffmpegthumbnailer we might consider removing kffmpegthumbnailer. But until it is not (and I don't feel that the developers have any intention to), I don't think we should remove it.
dirkvdb
Maybe you're aware that there is an actively maintained fork of ffmpegthumbnailer in the KDE project, called ffmpegthumbs. While I don't know the reasons for the initial fork, both this repo and the fork also have a version of the KDE-specific thumbnailer plugin based on ThumbCreator. In this repo, it's in the kffmpegthumbnailer directory, and over there it's in the top-level directory. It seems like these have drifted apart a bit, but kffmpegthumbnailer in here doesn't seem to get updated much (apart from my own recently merged pull request which I plan to incorporate into ffmpegthumbs as well).
I think it's worth at least considering the option of completely removing kffmpegthumbnailer from this repo. It is a pretty simple KDE-specific component, and as such is certainly more actively maintained within KDE itself. Having two versions of it doesn't seem to make much sense to me and having to get changes into both repos seems like a waste of time.
I'm not sure about the implications of doing that though. It might mean that KDE users who installed ffmpegthumbnailer but not ffmpegthumbs suddenly and inexplicably lose their video thumbnailer until they figure out they have to install ffmpegthumbs as well. But maybe that's a problem for package maintainers to deal with.