[kaffeine] [Bug 398808] Compilation of Kaffeine 2.0.15 + mplayer
https://bugs.kde.org/show_bug.cgi?id=398808 --- Comment #5 from knossos456 --- Xine is working properly and fluent , stand alone or under Kaffeine up to 1.2.2 for up to h.264 HD content. h.265 is a other story. All HD is H.264 here, and i haven't the hardware ressources ( GPU and CPU) to test Uhd with players (windows or ubuntu) Shame the VLC wasen't corrected for Radeon 5000 familly, all other players are working fine , Windows also, 3 % cpu for hd content with vdpau or under windows. I will try to post a bug report as you have reported. I'm exiting to see if kaffeine is still working with gstreamer. -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 398808] Compilation of Kaffeine 2.0.15 + mplayer
https://bugs.kde.org/show_bug.cgi?id=398808 --- Comment #4 from Mauro Carvalho Chehab --- (In reply to Mauro Carvalho Chehab from comment #3) > (In reply to knossos456 from comment #2) > Once I played with the idea, but never had time to do any serious stuff. I > guess I found somewhere a Gstreamer backend for Kaffeine (I guess it was on > some version 0.9x). I suspect it shouldn't be that hard to make it work > again, but it would require a lot more time than I have to dedicate on > userspace projects nowadays. Yeah, Kaffeine 0.87 used either gstreamer or xine as backend: $ ls kaffeine-0.8.7/kaffeine/src/player-parts dummy-part gstreamer-part kaffeine-part Makefile.am Makefile.in README xine-part (I extracted its source from a Fedora RPM file) The backends README of such version used to say: - xine-part This is the default (and recommended) player part for kaffeine using xine-lib. - gstreamer-part This is an experimental player part using GStreamer. As far as I remember, on that time, Xine were very stable and well maintained, and Gst was the new kid in the block. -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 398808] Compilation of Kaffeine 2.0.15 + mplayer
https://bugs.kde.org/show_bug.cgi?id=398808 --- Comment #3 from Mauro Carvalho Chehab --- (In reply to knossos456 from comment #2) > Thanks for quick answer. > > I have not a proprietary GPU stack , but the one comming with bionic .. I suspect that bionic has both the open source and the closed source drivers. If you're using an open source driver, you could try to open a bug at freedesktop and/or at vlc. > I have try to compile kaffeine 1.2.2 from source ( that is running with > xine). > I had to do with aptitude to install qt4 libs, but finally v 1.2.2 runs > fluently also on bionic , some icons are missing, haven't finalized the > patches. > > Just to say kaffeine with xine was a must for video .., really. > But i have look inside the source, backend kaffeine-xbu etc stuff, > complicated... xine has issues on its own, as it is not maintained for a *long* time. It probably won't allow you to use channels with h.264/h.265. Also, if you look at the Kaffeine's closed bug reports, you'll see hundreds of bugs due to it. > If you have a project with Gstreammer yes i would try of course. Once I played with the idea, but never had time to do any serious stuff. I guess I found somewhere a Gstreamer backend for Kaffeine (I guess it was on some version 0.9x). I suspect it shouldn't be that hard to make it work again, but it would require a lot more time than I have to dedicate on userspace projects nowadays. > > I've send you a mail for my DVB-T patch proposal .. -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 398808] Compilation of Kaffeine 2.0.15 + mplayer
https://bugs.kde.org/show_bug.cgi?id=398808 --- Comment #2 from knossos456 --- Thanks for quick answer. I have not a proprietary GPU stack , but the one comming with bionic .. I have try to compile kaffeine 1.2.2 from source ( that is running with xine). I had to do with aptitude to install qt4 libs, but finally v 1.2.2 runs fluently also on bionic , some icons are missing, haven't finalized the patches. Just to say kaffeine with xine was a must for video .., really. But i have look inside the source, backend kaffeine-xbu etc stuff, complicated... If you have a project with Gstreammer yes i would try of course. I've send you a mail for my DVB-T patch proposal .. -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 398808] Compilation of Kaffeine 2.0.15 + mplayer
https://bugs.kde.org/show_bug.cgi?id=398808 --- Comment #1 from Mauro Carvalho Chehab --- (In reply to knossos456 from comment #0) > I have a question , I haven't found the method. > > I have big problems with VLC and my Radeon 5450 . > Under vdpau it stutter every 4- 5 seconds on HD content. Well proprietary GPU stacks are usually full of bugs, and don't work too well. > Mplayer and Xine works perfectly with same content. > > As i have read that vlc is a bad player with old graphic cards ( i haven't > found the correct setting to play fluently a simple HD movie ) , i'm > searching the method to compile Kaffeine with Mplayer instead vlc. > > I have see backend-mplayer source sub directoty, but haven't found the > method to compile Kaffeine to use mplayer. > > Can somebody help (or if it is outdated why not delete it in repo ? or put a > comment it is not working ...) Kaffeine had an option in the past to work with different backends. That was during a period of time where it as transitioning to use a different backend. The code there at backend-mplayer is for that time. On older versions, it used lib-xine. This was replaced by vlc in 2011: commit e31652b06cc46dde488804b09205487d8036114f Author: Christoph Pfister Date: Sat Apr 30 18:48:07 2011 +0200 switch from (lib-)xine to (lib-)vlc - many issues (esp. crashes) vanish / are easier to fix - likely you need the 'full' vlc package (with X11 plugins) - this commit introduces introduces various regressions ;-) - big picture problems with libvlc: - dvd navigation (likely solved with libvlc 1.2 once it's released) - VDPAU - make MediaWidget more state-orientated, i.e. separate between - functions, which modify the state (e.g. a signal from the backend) - functions, which rely on the state (e.g. ui updates) The support for mplayer happened for a while, until it got removed, back in 2012: commit 05841ede2f902b3a47da6cbb2fd9edc069224abb Author: Christoph Pfister Date: Sun Mar 4 12:57:46 2012 +0100 stop mplayer experiment (--> vlc) The code changed a lot since then, and, even if you revert that patch, other changes would be required for it to work. Anyway, if you're interested on developing support for another backend, I would, instead, try to use Gstreamer, as it provides a more controllable approach. -- You are receiving this mail because: You are watching all bug changes.
