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
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
