Version: unspecified (using KDE 4.5.1) OS: Linux Distros also have ffmpegthumbnailer package seperately. So, kdemultimedia may use existing ffmpegthumbnailer package from system instead of compiling bundled ffmpegthumbnailer from kdemultimedia itself. Reproducible: Didn't try
Add Andreas Scherf to CC.
Pass -DBUILD_ffmpegthumbs=OFF to cmake?
I did some changes inside ffmpegthumbs. But in the next days i will commit some changes and will have a look on that problem.
(In reply to comment #2) > Pass -DBUILD_ffmpegthumbs=OFF to cmake? I want to use ffmpegthumbs from kdemultimedia, but I want it to use external ffmpegthumbnailer instead of the bundled one. By the way, thanks Andreas.
Sure you want to split ffmpegthumbnailer and the k component. I must look at the changes inside the ffmpegthumbnailer if it is possible. Cheers Andreas Am 2010 9 21 10:23 schrieb "Gökcen Eraslan" <gokcen@pardus.org.tr>: > https://bugs.kde.org/show_bug.cgi?id=251894 > > > > > > --- Comment #4 from Gökcen Eraslan <gokcen pardus org tr> 2010-09-21 10:23:53 --- > (In reply to comment #2) >> Pass -DBUILD_ffmpegthumbs=OFF to cmake? > > I want to use ffmpegthumbs from kdemultimedia, but I want it to use external > ffmpegthumbnailer instead of the bundled one. > > By the way, thanks Andreas. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug.
Gökcen, why the separate package dependency? The thumbnailer doesn't much more than calling into libffmpeg to get a video frame. And what it _does_ more isn't needed in the KDE thumbnailer (conversion to PNG or JPEG).
(In reply to comment #6) > Gökcen, why the separate package dependency? The thumbnailer doesn't much more > than calling into libffmpeg to get a video frame. And what it _does_ more isn't > needed in the KDE thumbnailer (conversion to PNG or JPEG). Some distros have a seperate ffmpegthumbnailer package: http://svn.pardus.org.tr/pardus/2009/devel/multimedia/graphics/ffmpegthumbnailer/ http://svn.mandriva.com/svn/packages/cooker/ffmpegthumbnailer/ http://www.archlinux.org/packages/community/i686/ffmpegthumbnailer/ http://packages.ubuntu.com/lucid/libffmpegthumbnailer4 it's a project lives in http://code.google.com/p/ffmpegthumbnailer/ What I'm trying to say is, embedding external libraries in applications, is not a good behaviour since it's both harder to maintain code duplicates from the perspective of package maintainers (for example if there is a patch about ffmpegthumbnailer, package maintainer will try to patch both ffmpegthumbnailer package and embedded ffmpegthumbnailers in other packages) and for security reasons. For example Debian has a list of embedded code copies: http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=file
Any news on this?
Hi, it hink, the way we go is ok. The ffmpegthumbnailer uses ffmpeg to create thumbnail files from videos. In kdemultimedia we use ffmpeg to create a stream to create thumbnails ... this is faster and more compilant. If we need an other solution we could talk about that. Cheers Andreas 2011/8/15 Harald Sitter <sitter@kde.org> > https://bugs.kde.org/show_bug.cgi?id=251894 > > > Harald Sitter <sitter@kde.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |sitter@kde.org > > > > > --- Comment #8 from Harald Sitter <sitter kde org> 2011-08-14 22:43:21 --- > Any news on this? > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. > _______________________________________________ > kde-multimedia mailing list > kde-multimedia@kde.org > https://mail.kde.org/mailman/listinfo/kde-multimedia >
The problem is distributing ffmpeg. Some distributions consider it to be too much of a legal risk and won't do it. So having a separate library that could be built and installed independently of the rest of kdemultimedia would allow distributions to avoid the legal risk while still allowing individual users or third-party repositories to provide support separately. Looking at the cmake output, it looks like Lame support is included without needed to build against lame. Something like that for ffmpeg might be acceptable, if it is possible.
"lame" is a command line tool, not a shared library, so this is an issue that using the ffmpegthumbnailer library would not solve. We have a thumbnailer that uses the "mplayer" command line tool, if you need such a type of optional dependency. The right way to solve that would be to use explicit dlopen calls to load the ffmpeg libraries. In other words, I still see no benefits for using yet another abstraction layer, that does not actually offer the interface we need (generating thumbnails directly to memory).
Our ffmpegthumbnailer is actually more of a fork, it doesn't invoke any ffmpegthumbnailer binaries but links against and uses ffmpeg libraries directly. ffmpegthumbnailer upstream also looks kind of dead (last release over a year ago).