On Tue, 2015-08-04 at 15:54 +0200, Martin Sandsmark wrote: > On Tue, Aug 04, 2015 at 03:25:59PM +0200, Reindl Harald wrote: > > VLC has for many codecs it's own implementations while it's > > *possible* to > > use external libraries instead the built-in ones in many cases > > This doesn't match what I know, from what I can see in the source the > modules > you listed simply call out to the necessary libraries to do the > actual > decoding? > > But I might have missed some codecs, so feel free to point out codecs > that > VLC implements itself, I might just be looking in the wrong parts of > the > source. > > > > just read http://www.videolan.org/vlc/ and guess why for MPEG-2, > > DivX, > > H.264, MKV, WebM, WMV, MP3... are no codec packages needed > > The VLC build system has functionality to let people download, build > and > bundle the libraries it depends on, for platforms where those aren't > available system-wide (the most prominent would probably be Windows > and OS > X). >
VLC is a complete client and it may be difficult to package libvlc separately. An alternative is building a libmpv Qt client for video playback. libmpv depends on ffmpeg for most things. Distributions can ship ffmpeg with disabled functionality to avoid linking against questionable libraries. The only issue is that ffmpeg itself probably contains code which prevents Redhat/Fedora from packaging it. But then again, VLC is a direct ffmpeg client and often doesn't compile without the latest ffmpeg code so the issue is there as well. As for audio, Clementine has a Qt5 port in git and it uses gstreamer which is very pluggable. Clementine uses udisks for supporting external media. It is a very mature product and works extremely well. Gstreamer remains the easiest and safest way to avoid patent issues by only shipping the plugins you want. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
