a vlc backend is plain stupid, no one has noticed that vlc is just a gui that put togheter a very rich set of different video API's, nobody here ever asked itself why vlc ask for mplayer libs? or ffmpeg libs or speex libs, etc? lol
Originally Posted by RealNC
vlc is not an engine or anything is something like kmplayer or dragon player, the only engines for video decoding are xinelib, gstreamer and shared with both ffmpeg, even mplayer is not entirely an engine but more like a cli gui for this libs too.
ok vlc ffmpeg trunk or mplayer could be a bit more polished if any but the problem here is the distros version of ffmpeg, libpostproc, x264, etc. compile kde 4.4 and all the multimedia api like libxine from scratch using vanilla code and you will see the diff, is not xine is the distros (ubuntu/debian/arch/opensuse as far i tested) wich bastardize or crappy backport stuff cuz they wanna use the "stable" "supported" version but using a kde version 1 year newer
OK, that makes sense, I was used to Kaffeine from Kde3 and Amarok, which all used xinelib directly, without problems.
Other bugs I encountered were a crash/hang when trying to play sound from a buffer and random crashes on non-Linux platforms. And Phonon upstream wasn't really interested in fixing them either.
It seems Qt had pretty much enough of Phonon too and it looks like they wrote their own multimedia framework in Qt 4.7 (QtMultimedia.)
VLC might rescue the situation for Phonon, but the VLC backend didn't receive a single Git commit for about a month now :-/
again the genius that created the tracker had to eventually find out that vlc is just a frontend of xine/ffmpeg/+ other libs, so pretty much deduced it was a useless effort to keep it going. again the issue are the distros wich backport stuff they shouldnt(see for example ubuntu kms/drm backport from 2.6.33 and 2.6.34-rcx to their 2.6.32 kernel and see how many issues they created, is not like kernel 2.6.32 is a crappy release cuz a vanilla 2.6.32 dont have any of those issues).
Originally Posted by RealNC
ok you wanna a clear example, download kubuntu 10.04 and install kffmpegthumbnailer(create thumbnails of video using ffmpeg) and create a theora encoded video, you will find out that the thumbnails are completely corrupted in theora videos, but if you compile the official ffmpeg from source the problem dissapear and all is peachy, now why ubuntu ffmpeg do that? cuz they are using the latest official release of ffmpeg wich is quite old but adding backports at hand to give the idea you have the new stuff, at the end if you keep the official ffmpeg libs you are going to have a bunch of issues with kde phonon and many other players with are dinamically linked to that library.
even vlc have issues in kubuntu like audio codec ai3!@ is not a recognized format, but with a vanilla ffmpeg the audio play perfectly fine.
now should be cool if someone if willing to recompile the entire multimedia stack from vannilla code and keep it in a PPA branch, so ppl can just upgrade their stack to a vanilla one to fix many of this issues, like xorg crackers for those who wanna test the latest bits in the xorg stack
The issues I had though were not related to backports. I was using latest upstream versions of KDE-Phonon and Xine.
well the problem isnt xine entirely, remember that xine/vlc/mplayer/gstreamer/sdl/god knows who else heavily depends on 3 libraries named:
Originally Posted by RealNC
these libraries in the majority of the cases are the responsibles for the decode of most codecs, and this libraries are basically FFMPEG, so even if you compile xinelib on your own, it will link to ffmpeg or give error cuz it cant find the headers of ffmpeg.
even if you recompile from git or stable both ffmpeg and xine you will still have a lot of issues with certain codecs like AAC/FLAC/x264/theora/ogg/vorbis/speex/xvid/AC3/DTS/rmb/quicktime/mpeg2/mp3/dvd decrypt/etc cuz all this library are called from ffmpeg or even xine but these are external libraries with their own backports generating issues(even in some lol cases, you find very widely known not to work version in those libraries in these distros stacks.), like the theora example i did, aka theora is not inside the ffmpeg codebase, ffmpeg call a function inside the theora library, wich is way diferent, so if you want the best experience with phonon or any other xine frontend you should compile from vanilla all the external libraries before compile ffmpeg and after that compile xine-lib and ovbiously the vanilla kde-multimedia package (yes ubuntu kde-multimedia package is very problematic or nerfed or backported who knows), i did that and never again got any sort of issues with phonon or any other xine/gstreamer front end
of course i understand is a very error prone and tedious task, but maybe somebody could make a PPA with all those packages
as a noteif you are using k/ubuntu 10.04 use a 2.6.34 kernel if you are using the oss driver, if you are stuck with fglrx well it should be ovbuios by now, that you will get a hell bunch of issues due the driver and unrelated to the libraries, in my case switch to the oss driver and recompile all the libs make my videos flawless and stable like a rock
I am using the latest upstream of *everything* on my system, be it ffmpeg, xine-lib or... glibc. (I'm on Gentoo Linux.)
And again: the issues are with Phonon's Xine backend, not xine-lib itself. My rant is simply about Phonon which doesn't seem able to get its act sorted out. xine-lib is perfectly fine for most stuff. It's Phonon that doesn't seem able to actually use it correctly.
... And it's not just the xine backend; Phonon can't even use GStreamer correctly it seems since there's no way to get a sound to loop gapless.
Phonon, as it is now, is only useful for "hello world"-style media playback.