[Nepomuk] Nepomuk - Moving away from Strigi

[Kevin Kofler]

On Monday 08 October 2012 at 22:26:30, Martin Gräßlin wrote:
> Neither Kevin (Fedora), Scott (Kubuntu) nor Adrian (SUSE) came up with the
> rules, they are just pointing out the policies. While I do not agree with
> their policies I can kind of understand it.
> 
> What everybody can do is to bring the question back to the distributions
> that they might reconsider the situation and bringing back the feedback
> that Upstream really wants to have working multimedia in the downstream.
> 
> Though especially for the distributions situated in the USA I have little
> hope that they might change anything. The patent system there is extremely
> broken and there is quite a difference between knowing that the software
> breaks patents or some bogous IP claims like SCO.
> 
> We all know that situation and we won't change it here on kde-devel. I'd
> love to do so, but it won't happen :-(
> 
> So let's all calm down and work on good solutions :-)

The best solution I can offer is: if at all possible, please (pretty please) DO 
NOT use FFmpeg (directly), use GStreamer.

There are 4 APIs you can use to use GStreamer in your application:
* Phonon (with Phonon-GStreamer, which is the default in most distributions). 
The highest-level API, suitable for simple playback, not so much for other 
tasks.
* QtMobility Multimedia. Listed for completeness, probably not ideal for KDE 
applications. Also high-level.
* QtGStreamer. Lower-level Qt bindings for GStreamer. More flexible.
* GStreamer directly. C/GObject API. Lowest-level, but not as low-level as 
FFmpeg. ;-) If even QtGStreamer does not do what you want, try this one.

Now I don't know whether GStreamer is suitable for the Nepomuk indexing task 
which started this thread, but e.g. for the Amarok transcoding and 
fingerprinting, it could definitely be used instead of the FFmpeg-based code we 
have now (see sound-converter (the GNOME one, not soundKonverter) for an 
example of how to use GStreamer for transcoding, transcoding is actually one 
of the things it can do well). Thumbnailing is also something which could and 
should be done using GStreamer rather than FFmpeg as ffmpegthumbnailer does.

GStreamer helps us in several ways:
* GStreamer is modular, so distros can ship only the codecs they feel safe and 
others can be added as plugins. (FFmpeg, on the other hand, links all the 
codecs into a single monolithic shared library.)
* GStreamer supports system decoding libraries for many formats. In 
particular, most unencumbered codecs can be decoded without depending on the 
monolithic FFmpeg. This approach also encourages code sharing rather than 
reinventing the wheel as FFmpeg loves to do.
* GStreamer supports FFmpeg (or actually Libav these days) codecs as one of 
the many plugins.
* GStreamer upstream actually cares about the legal issues and already 
classifies the stable codecs into "good" and "ugly". (The less-proven "bad" 
ones, on the other hand, are not classified by upstream and are split into 3 
pieces in Fedora and RPM Fusion: free and patent-free, free but patent-
encumbered and outright non-free. But that's just a matter of auditing the 
plugins and splitting them, interested third parties can look at our split.)
* If everything uses GStreamer, the user only has to add the "evil" codecs 
once for all apps. (And there's even a codec auto-installation feature, though 
admittedly that will only work if the repository containing the codec is 
already configured, so it's not a magic bullet.) If, on the other hand, we go 
with the alternative solution of having FFmpeg-based plugins for everything, 
sure, that also solves our problem (as long as they're really plugins, not 
compile-time options like Amarok's fingerprinting!), but it means the user has 
to install a lot of *-ffmpeg packages to get everything working.

So in short, if you want multimedia to "just work" in your software, use 
GStreamer!

        Kevin Kofler