Naja, mittlerweile hat es der xine geschafft, sich meine Gunst als Lieblingsplayer (genauer: library, da kaffeine-Nutzer) zu erwerben, aber dennoch ein "Bravo, weiter so!" an die mplayer-Programmierer, weil Auswahl nun mal was feines ist und ich den Platz für den mplayer immer freihaben werde. Das schöne dabei ist: habe ich irgendwelches kritisches oder defektes Material, das der eine player nicht schafft, schafft's meist der andere, weswegen ich mir immer gleichzeitig xine und mplayer auf meinen Computern halte. Und da halten die Leute Vielfalt für was schlechtes
Die xine-lib basiert auf der ffmpeg, ohne mplayer würde es auch kein xine geben. Besser als mplayer finde ich allerdings den mencoder, das Teil ist einfach unschlagbar. Schade nur, dass es so wenig Nutzer hat
du weißt aber schon, dass mplayer ein player ist und mencoder ein (de-)codier-tool. das kann man nicht wirklich vergleichen, aber genial ist beides allemal!
und deswegen ein freudiges hell yeah an die progammierer. ein heiß ersehntes release und viel viel vorfreude schon auf den fertigen release 1.0.
Von Manfred Tremmel am Di, 24. Oktober 2006 um 12:29 #
Klar, die xine-lib basiert zu großen Teilen auf ffmpeg, wie es auch der MPlayer tut. Wieso es aber xine jetzt ohne MPlayer geben würde, verstehe ich nicht ganz. Gut, ffmpeg wird mittlerweile auf der MPlayer Seite gehostet, aber es ist keine ausgliederung aus dem MPlayer. Richtig ist, ohne ffmpeg wäre weder xine noch MPlayer das, was sie heute sind, nämlich universelle Mediaplayer, die (fast) jedes Format abspielen können.
Ansonsten kann ich mich nur in die Liste der Gratulanten einreihen, ich nutze zwar auch primär Kaffine + xine-lib, aber deswegen ist der MPlayer auch ein genialer Mediaplayer, er wird hier immer auch mit installiert (auch wegen mencoder). Es ist ja auch schön, dass sich die beiden Porjekte gegenseitig befruchten, Codetransfer in beide Richtungen ist ja da an der Tagesordnung.
Von Anonymous Coward am Mo, 23. Oktober 2006 um 13:38 #
Irgendwie finde ich es ziemlich komisch. mplayer ist einer *der* Player schlechthin für Linux und BSD - aber dennoch werden für Windows Binaries bereitgestellt und unter Linux darf ich selber kompilieren - was soll das? Ich bin Linuxuser, aber ich habe trotzdem keine Lust, bei jeder Gelegenheit irgendwelchen Quatsch selber zu kompilieren. Ein paar .debs oder .rpms sind glaube ich nicht zu viel verlangt! Naja, ist ja wurscht. Jedenfalls toll, dass mplayer so schön weiterentwickelt wird.
Von Anonymous Coward am Di, 24. Oktober 2006 um 10:35 #
Diese Meinung kannst Du mit Sicherheit auch begründen. Ansonten: düse ist nur ein Troll einfach ignorieren, der hat keine Ahnung. (die Schreibfehler entsprechen dem Original)
Von Anonymous Coward am Di, 24. Oktober 2006 um 10:33 #
_Keine_ Distri liefert für mich hinreichend aktuelle Pakete, außer den unstable-Versionen und da ist der Name Programm. Unter Windows hat man auf Wunsch immer die aktuellste Version und trotzdem ein stabiles System (wenn man es zu administrieren weiß).
Teilweise solltest du froh drüber sein, bei "offiziellen" Distrie-Kompilaten könnte es passieren, dass diese aus rechtlichen Gründen lieber eine kastrierte Version des mplayer bereitstellen würden, die dann auf ein Mal bestimmte Formate nicht mehr mag. Bequemlichkeit hin und her, aber wenn man sich dafür wieder Nachteile einhandelt, würde ich mir das jedenfalls immer mal überlegen, so schwer ist der Kompilier-Dreisatz nun auch nicht, wenn man dafür die "Vollversion" bekommt
> so schwer ist der Kompilier-Dreisatz nun auch nicht, wenn man dafür die "Vollversion" > bekommt
Schwierig nicht, aber aufwändig. Codecs besorgen, kompilieren, und bei jedem Update (was man manuell checken muss) wieder von vorne. Ich kann jeden verstehen, der darauf keine Lust hat.
mplayer lohnt sich echt selbst compilieren, der optimiert automatisch auf die eigene CPU, sehr praktisch. FastFourier läuft sehr viel schneller wenn der Code auf die CPU angepasst wird, im Prinzip eines der wesentlichen Dinge wo das ganze SSE, MMX und haumichblau wirklich mal einen deutlichen Vorteil bringt.
Lohnt sich das denn auf halbwegs aktuellen Prozessoren? Vielleicht für mencoder, aber zum gewöhnlichen Abspielen von Video- und Audio-Dateien dürften die Optimierungen heutzutage überflüssig sein. Naja, vielleicht spart es ja ein paar wenige Prozent CPU-Auslastung...
spätestens ab HDTV lohnt es sich auch für das Abspielen Also für normals Abspielen über Xv lohnt es nicht, aber wer die Postprocessing-Filter nutzt und auf Qualität achtet für den lohnt es sich schon. Für mencoder lohnt es auf jeden Fall.
Seit wann funktioniert XvMC mit Mpeg4 oder VC1? Seit wann unterstützt XvMC gute Deinterlacing Algorithmen? Seit wann funktioniert das zusammen mit Postprocessing-Filtern?
XVMC ist ein Linux-Marketing-Begriff und nur sehr eingeschränkt zu gebrauchen.
Seit wann funktioniert XvMC mit Mpeg4 oder VC1? Frag NVIDIA, wann sie den Treiber entsprechend ergänzen.
XVMC ist ein Linux-Marketing-Begriff und nur sehr eingeschränkt zu gebrauchen. Auch unter Windows gibt es Hardware-Beschleunigung durch die Grafikkarte und auch da ist man auf simple Deinterlacing-Verfahren wie Bob beschränkt. Das macht bei progressive aber nichts.
Meistens sind ja Binaries ganz ok. Na ja, aber beim MPlayer? Für einen stino-User vielleicht.
Für die anderen aber: Bei den vielen Optionen, die MPLayer so mit sich bringt, müssten dann die Distributoren alle möglichen Varianten als Paket bereitstellen ... bleibt am besten also doch der Selbstbau ;-) Und natürlich mit checkinstall als Paket ;-)
Bei den vielen Optionen, die MPLayer so mit sich bringt, müssten dann die Distributoren alle möglichen Varianten als Paket bereitstellen Nein, *eine* Variante mit sämtlichen Codecs reicht.
> Nein, *eine* Variante mit sämtlichen Codecs reicht.
Wie soll denn dass funktionieren ? Soll der PC mit Funktionen und deren Abhängigkeiten vollgestopft werden, die nur Resourcen beanspruchen und die man nicht benötigt?
Z.B ruckelfreie DVD-Wiedergabe geht so ab 300 MHz-PC. Aber nicht im GUI-Modus. Im Konsolen-Mode mit einer Latte Optionen. Soll dieser alte PC mit GTK-Paketen und anderen Libraries oder sämtliche Sprachunterstüzung zugemüllt werden?
Übrigens, die MPlayer manpage, sowie die Fehlerausschriften und auch Tips sind somit das Ausführlichste was ich so je gesehen habe: Alle Achtung den Programmierer und Übersetzer!
Soll der PC mit Funktionen und deren Abhängigkeiten vollgestopft werden, die nur Resourcen beanspruchen und die man nicht benötigt? Aktuelle Rechner verfügen über massig Festplattenspeicher und RAM. Da kommt es auf die paar MB auch nicht mehr an.
Z.B ruckelfreie DVD-Wiedergabe geht so ab 300 MHz-PC. Aber nicht im GUI-Modus. In solchen Extremfällen kompiliert man sich das Teil sowieso selbst. Für den "normalen" Gebrauch auf einem "Multimedia-Computer" reichts aber, wenn das Paket mit sämtlichen Codecs vorkompiliert wurde. Beim MPlayer ist eh vieles statisch einkompiliert, weshalb sich die Abhängigkeiten in Grenzen halten.
Soll dieser alte PC mit GTK-Paketen und anderen Libraries oder sämtliche Sprachunterstüzung zugemüllt werden? Wer installiert auf so nem alten PC schon eine Distribution wie SUSE oder Fedora Core, die schon für die Installation mal eben 256 MB RAM benötigen? Außerdem werden für die Sprachunterstützung nur einige gettext-MachineObjects abgelegt. Wenn du dich schon hier beschwerst, was ist dann mit coreutils und Co.? Auch da wird deine Festplatte mit MachineObjects für nicht benötigte Sprachen "zugemüllt". Da interessiert es aber niemanden. Warum also bei MPlayer?
> ämtlichen Codecs vorkompiliert wurde gibts wohl irgendwie rechtliche probleme?
> Außerdem werden für die Sprachunterstützung nur einige gettext-MachineObjects abgelegt. ---> sämtliche meldungen, einschliesslich tips und hinweise, mehrtausend-seitige manpage kommen in der sprache der wahl
> Beim MPlayer ist eh vieles statisch einkompiliert, bei deinen rpm's vielleicht, mach doch mal ./configure - aber solange bis alle abhängigkeiten mit [yes] ausgegeben werden
nach .configure und make brach es dann bei checkinstall leicht ab:
install -m 755 -p libdha.so.1.0 /usr/local/lib/libdha.so.1.0 install: Erhalten der Zeiten für ,,/usr/local/lib/libdha.so.1.0": Datei oder Verzeichnis nicht gefunden install: Setzen der Zeitstempel für ,,/usr/local/lib/libdha.so.1.0" nicht möglich: Datei oder Verzeichnis nicht gefunden make[1]: *** [install] Fehler 1
Aber nach manuellen Kopieren von # cp ..../MPlayer-1.0rc1/libdha/libdha.so* /usr/local/lib
lief es dann durch ;-)
Schade, die verschlüsselten (?) wmv's laufen immer noch nicht ;(
Tja, fast alle Skins sehen nach irgendwas Tollem aus, nur nicht nach einem benutzbaren grafischen Userinterface. Deshalb bleibe ich lieber bei der Kommandozeilenversion :-).
Gibt's eine Möglichkeit, dem MPlayer Menüunterstützung bei DVDs beizubringen? Oder ist es in absehbarer Zukunft zur Implementierung geplant?
Denn dies ist der Knackpunkt, ob MPlayer bei mir über ein Nischendasein hinauskommt, was ich mir durchaus wünschen würde. Andere wie Xine oder das schon leicht angestaubte Ogle oder VLC können's schließlich, machbar müsste es also sein.
Der wahre MPlayer-User ist Tastatur-Junkie (MPlayer lässt sich eh nicht gescheit mit der Maus steuern) und will direkt in den Hauptfilm wechseln. Auf die "umständliche" Navigation durch das DVD-Menü hat er keine Lust.
Mir geht es nur um Videos. Flash selber als Menüsystem interessiert mich nicht. Naja, wenn Mplayer das nicht so gut kann, setz ich halt Flash9 ein. Leider benötigt es recht viele Resourcen und ich hätte so ein 500Mhz Internetterminal für zu Hause. Mit Mplayer und mplayerplugin wollte ich das Problem umgehen. Einzig für wetter.de hätte ich mir irgendwas gebastelt (z.b. Opera mit Flash9 nur für wetter.de), weil ich ausser den Videoseiten absolut keine Flashseiten benötige.
Vielen Dank für die neue Version und überhaupt Dankeschön, das es meinen lieblingsplayer überhaupt gibt.
Also schön fleißig weiter entwickeln!!!
Nicht ausschließlich. Für DVDs reichen z.B. liba52 und libmpeg2. Da wird kein Code der libavcodec benötigt.
und deswegen ein freudiges hell yeah an die progammierer. ein heiß ersehntes release und viel viel vorfreude schon auf den fertigen release 1.0.
so long... johannes
Ansonsten kann ich mich nur in die Liste der Gratulanten einreihen, ich nutze zwar auch primär Kaffine + xine-lib, aber deswegen ist der MPlayer auch ein genialer Mediaplayer, er wird hier immer auch mit installiert (auch wegen mencoder). Es ist ja auch schön, dass sich die beiden Porjekte gegenseitig befruchten, Codetransfer in beide Richtungen ist ja da an der Tagesordnung.
Naja, ist ja wurscht. Jedenfalls toll, dass mplayer so schön weiterentwickelt wird.
Ansonten:
düse ist nur ein Troll einfach ignorieren, der hat keine Ahnung.
(die Schreibfehler entsprechen dem Original)
Du werden sehen du glücklich, blindes auge muss besser hinschauen.
> bekommt
Schwierig nicht, aber aufwändig. Codecs besorgen, kompilieren, und bei jedem Update (was man manuell checken muss) wieder von vorne. Ich kann jeden verstehen, der darauf keine Lust hat.
Nö, da lohnt sich eher XvMC.
XVMC ist ein Linux-Marketing-Begriff und nur sehr eingeschränkt zu gebrauchen.
Frag NVIDIA, wann sie den Treiber entsprechend ergänzen.
XVMC ist ein Linux-Marketing-Begriff und nur sehr eingeschränkt zu gebrauchen.
Auch unter Windows gibt es Hardware-Beschleunigung durch die Grafikkarte und auch da ist man auf simple Deinterlacing-Verfahren wie Bob beschränkt. Das macht bei progressive aber nichts.
Na ja, aber beim MPlayer? Für einen stino-User vielleicht.
Für die anderen aber:
Bei den vielen Optionen, die MPLayer so mit sich bringt, müssten dann die Distributoren alle möglichen Varianten als Paket bereitstellen ... bleibt am besten also doch der Selbstbau ;-)
Und natürlich mit checkinstall als Paket ;-)
bye sumsi
Nein, *eine* Variante mit sämtlichen Codecs reicht.
So outen sich "Profis"
Wie soll denn dass funktionieren ?
Soll der PC mit Funktionen und deren Abhängigkeiten vollgestopft werden, die nur Resourcen beanspruchen und die man nicht benötigt?
Z.B ruckelfreie DVD-Wiedergabe geht so ab 300 MHz-PC. Aber nicht im GUI-Modus.
Im Konsolen-Mode mit einer Latte Optionen.
Soll dieser alte PC mit GTK-Paketen und anderen Libraries oder sämtliche Sprachunterstüzung zugemüllt werden?
Übrigens, die MPlayer manpage, sowie die Fehlerausschriften und auch Tips sind somit das Ausführlichste was ich so je gesehen habe: Alle Achtung den Programmierer und Übersetzer!
Aktuelle Rechner verfügen über massig Festplattenspeicher und RAM. Da kommt es auf die paar MB auch nicht mehr an.
Z.B ruckelfreie DVD-Wiedergabe geht so ab 300 MHz-PC. Aber nicht im GUI-Modus.
In solchen Extremfällen kompiliert man sich das Teil sowieso selbst. Für den "normalen" Gebrauch auf einem "Multimedia-Computer" reichts aber, wenn das Paket mit sämtlichen Codecs vorkompiliert wurde. Beim MPlayer ist eh vieles statisch einkompiliert, weshalb sich die Abhängigkeiten in Grenzen halten.
Soll dieser alte PC mit GTK-Paketen und anderen Libraries oder sämtliche Sprachunterstüzung zugemüllt werden?
Wer installiert auf so nem alten PC schon eine Distribution wie SUSE oder Fedora Core, die schon für die Installation mal eben 256 MB RAM benötigen? Außerdem werden für die Sprachunterstützung nur einige gettext-MachineObjects abgelegt. Wenn du dich schon hier beschwerst, was ist dann mit coreutils und Co.? Auch da wird deine Festplatte mit MachineObjects für nicht benötigte Sprachen "zugemüllt". Da interessiert es aber niemanden. Warum also bei MPlayer?
gibts wohl irgendwie rechtliche probleme?
> Außerdem werden für die Sprachunterstützung nur einige gettext-MachineObjects abgelegt.
---> sämtliche meldungen, einschliesslich tips und hinweise, mehrtausend-seitige manpage kommen in der sprache der wahl
> Beim MPlayer ist eh vieles statisch einkompiliert,
bei deinen rpm's vielleicht, mach doch mal ./configure - aber solange bis alle abhängigkeiten mit [yes] ausgegeben werden
install -m 755 -p libdha.so.1.0 /usr/local/lib/libdha.so.1.0
install: Erhalten der Zeiten für ,,/usr/local/lib/libdha.so.1.0": Datei oder Verzeichnis nicht gefunden
install: Setzen der Zeitstempel für ,,/usr/local/lib/libdha.so.1.0" nicht möglich: Datei oder Verzeichnis nicht gefunden
make[1]: *** [install] Fehler 1
Aber nach manuellen Kopieren von
# cp ..../MPlayer-1.0rc1/libdha/libdha.so* /usr/local/lib
lief es dann durch ;-)
Schade, die verschlüsselten (?) wmv's laufen immer noch nicht ;(
Die Linuxversion auch. Nennt sich gmplayer.
http://www.mplayerhq.hu/images/skins/AlienMind-01.jpg
http://www.mplayerhq.hu/images/skins/PowerPlayer-01.jpg
http://www.mplayerhq.hu/images/skins/JiMPlayer-01.jpg
http://www.mplayerhq.hu/images/skins/xine-lcd-01.jpg
http://www.mplayerhq.hu/images/skins/Abyss-01.jpg
schade, das die während des filmes vom bild verdeckt werden :-)
bye
Das hier dagegen schon
fast alle Skins sehen nach irgendwas Tollem aus, nur nicht nach einem benutzbaren grafischen Userinterface. Deshalb bleibe ich lieber bei der Kommandozeilenversion :-).
Konnte beim ersten Test nix entdecken....oder brauch man ev nen anderne Skin dazu!?
das bild ist doch nicht grösser als der rahmen...
Das Standart-Skin jedenfalls (Blue Plastik) hat da so eine Art Schieberegler, das GUI kmplayer auch ..
Denn dies ist der Knackpunkt, ob MPlayer bei mir über ein Nischendasein hinauskommt, was ich mir durchaus wünschen würde. Andere wie Xine oder das schon leicht angestaubte Ogle oder VLC können's schließlich, machbar müsste es also sein.
Oder besteht bei den Fans da einfach kein Bedarf?
mplayer dvdnav://
eventuell muss man mouse-movements=1 in der ~/.mplayer/config setzen.
Funktioniert bei manchen DVDs ganz gut, bei manchen stürzt er ab ...
aber vielen dank an das mplayer team fuer diese grandiose software...!
Danke!
PS: ja, Flash9 gäbe es auch noch... war ja nur ne Frage...
Und es bereits eine Beta für Flash9 gibt?
Trotzdem hält es mich nicht ab nachzufragen, ob der MPlayer nun Flash-Videos aller Art abspielen kann
Onlinemagazine (Spiegel) setzen teilweise auf die 9er Version, da hat man etwas nachsehen ...
Leider benötigt es recht viele Resourcen und ich hätte so ein 500Mhz Internetterminal für zu Hause. Mit Mplayer und mplayerplugin wollte ich das Problem umgehen. Einzig für wetter.de hätte ich mir irgendwas gebastelt (z.b. Opera mit Flash9 nur für wetter.de), weil ich ausser den Videoseiten absolut keine Flashseiten benötige.