Wie MPlayer richtig einstellen ? (XVID)

[Kinehs]

Servus!

Ich nutze Suse 9.3 Prof und habe nun den MPlayer installiert, sowie den XVid codec, die w32codecs und die benötigten Pakete für den MPlayer.

Leider kann ich nur den Sound diverser XVid Movies hören, Bild bekomme ich keins zu sehen.

Was habe ich falsch gemacht/vergessen?

[whatever]

ist ffmpeg installiert?
im "notfall" halt den mplayer selber compilen und ffmpeg explizit angeben

[Kinehs]

nein, ffmpeg ist nicht installiert. Ich habe es mir geladen und er fragt wieder nach 4 anderen Paketen.

Hört das eigentlich mal auf?

Ich habe alles in Zusammenhang mit Multimedia installiert, da sollte ich doch wenigstens einfach ein Video abspielen können.

Grrr.

[Kinehs]

Also ich gebs auf. Einige Pakete finde ich im Netz gar nicht, die angeblich benötigt werden.

Gibt es keinen einfachen Guide wie man solche Videos schnellstmöglich unter Suse zum laufen bekommt?

[ActionNews]

Also unter SuSe 9.3 nutze ich lieber Xine.

Am Besten schausst du mal hier:
http://packman.links2linux.de/index.php4?action=124&vn=2 (Punkt a) sollte reichen, aber auch die zusätzlich benötigten Pakete für a) am ende der Seite installieren!)
und eine passende UI dazu: http://packman.links2linux.de/index.php4?action=125&vn=2

Dann solltest du eigentlich alles abspielen können was es so gibt. Man kann packman.links2linux.de auch als Yast-Quelle angeben, dann kannste auch einfach mit Yast2 aktualisieren, aber da weiss ich die genauen Einstellungen nimmer.

CU Michael

[Rhönpaulus]

wieso lädst du einfach nicht den quellcode und compilierst ihn selber?
so schwer ist das ja nun wirklich nicht.
ffmpeg ist dann integriert,ebenso wie andere codecs so du diese vor dem compilieren von mplayer schon installiert hast.
danach benötigst du für die grafische gui nur noch skins und mindestens einen osd-zeichensatz und schon rennt das ganze wie hanne.

[Harleckin]

wieso lädst du einfach nicht den quellcode und compilierst ihn selber?
so schwer ist das ja nun wirklich nicht.
ffmpeg ist dann integriert,ebenso wie andere codecs so du diese vor dem compilieren von mplayer schon installiert hast.
danach benötigst du für die grafische gui nur noch skins und mindestens einen osd-zeichensatz und schon rennt das ganze wie hanne.
Ich dacht eigentlich SuSIE wäre was für ein Einsteiger/Umsteiger. :|

[Rhönpaulus]

mag sein aber gerade bei suse funktioniert doch gerade wegen irgendwelcher vorcompilierter bins nichts richtig.
den mplayer unter einer grafischen oberfläche selber zu backen ist nun wirklich auch von jedem anfänger zu bewerkstelligen der ein konsolenfenster öffnen und drei befehle eingeben kann.
ich bin überzeugt das bei mplayer diese methode wesendlich weniger ärger macht da mplayer ein sehr ausgefeiltes configurationsscript besitzt.
anleitungen dazu gibt es zur genüge.

[Harleckin]

Nun, es mag dahin gestellt sein, welch Umfang nun genau benötigt wird, um mplayer zu kompilieren.
Die Crux an der Geschichte liegt im Detail..

1.) baut man _nicht_ selbst ein Paket, umgeht man "meist" das Paketmanagement und schneidet sich im Endeffekt ins eigene Fleisch
2.) Aufwand - Nutzen Relation. Die investierte Zeit zum Studium der INSTALL Anleitung und das Erfüllen der Abhängigkeiten verschlingt einen Großteil der Zeit.
3.) wer stellt die Aktualität und Abhängigkeiten später sicher? kommt eine neue Version heraus, geht das ganze Spiel von vorne los.
4.) installiert man ein Programm aus den Quellen, sollte man wenigsten wissen, was man da nun genau tut. Wer blind irgendwelche Befehle eingibt, brauch später nicht heulen.

Tja, mplayer ist ein ekzellentes Beispiel für die Misere von u.a. SuSIE.

Ich rate jeden Einsteiger/Umsteiger dazu ab, Pakete selbst zu kompilieren. Eher sollte man die Zeit nutzen Quellen (wie packman.links2linux.de) zu finden und sich mit dem Paketmanagement der Distro auseinander setzen.

Schätzt man es dagegen Programme aus den Quellen zu bauen, fährt man IMO mit SuSIE den falschen Karren.

[Rhönpaulus]

nun ich nutze mplayer seit jahren und habe das damals selbst als blutiger linuxanfänger unter redhat ohne weiteres hinbekommen.
den pre7 habe ich vor zwei wochen installiert,zeitaufwand etwa 20 min.

im prinzip ist das ganz easy.


mplayer-quellcodepacket,benötigte codecs,skins und zeichsatz saugen
codecs entpacken und installieren
mplayerpacket entpacken,zum bsp. nach /usr/local/src
auf der gui in den entpackten ordner wechseln und konsolenfenster öffnen
./configure --enable-gui
make
make install
skins und zeichensatz nach /usr/local/share/mplayer kopieren
verknüpfung für gui-mplayer auf den desktop erstellen


mehr isses nicht wenn man keine speziellen optionen von mplayer benötigt.
ffmpeg spielet alles ab was irgendie mit mpegfiles zu tun hat incl. divx und xvid,außerdem ist er hochoptimiert und sehr schnell
extra codecs benötigt man eigendlich nur für properitäre videos wie wma oder realmedia.

ohne suse selber zu kennen gehe ich jetzt mal davon aus das es darauf auch nicht anders läuft.

[Harleckin]

warum so umständlich?! hat dies irgendeinen offensichtlichen Vorteil?

Ich will keine Grundsatzdiskussion vom Stapel lassen, aber meinst du nicht selber, dass du dir die Arbeit ersparen könntest? Jede bessere Distro bietet ein Paketmanagement an und das Auffinden von Paketen erweist sich weniger zeitaufwendig.


deb http://ftp.nerim.net/debian-marillat/ sarge main


apt-get update
apt-get install mplayer-686 mplayer-fonts mplayerplug-in


Nun, der nächste macht es unter Gentoo, Arch, etc. vergleichbar. Wiederrum ein Anderen nutzt apt4rpm. Im Grunde genommen läuft es auf das Gleiche heraus.

[Rhönpaulus]

ich muß das selber compilieren weil ich eine spezielle funktion brauche um als ausgabedevice die dvb-s-karte zu nutzen.
vorgefertigte binärfiles nützen mir nichts.
da der treadstarter offenbar größere probleme hat die richtigen bins zusammen zu bekommen ist die nächstbeste installationsoption das selberbacken.
apt4rpm ist natürlich auch ein komfortabler weg wenn man es eingerichtet hat und die installierten files für die eingenen zwecke richtig konfiguriert sind.

[Harleckin]

Klar, ist natürlich verständlich, dass es mal Abweichungen zwischen den Binärpaketen gibt, wie in deinen Fall.

Aber dies ist bei weiten kein Grund, gleich das Pakatemanagement aus zu hebeln.

Ich erkläre es kurz an Hand von Debian GNU/Linux..

deb-src http://ftp2.de.debian.org/debian/ sarge main non-free contrib
deb-src http://ftp.nerim.net/debian-marillat/ sarge main


# apt-get build-dep mplayer // libpng12-dev oder aalib1-dev vorher installieren
$ apt-get source mplayer

Man nehme die Änderungen an den Quelltext bzw. FLAGS vor und baut sauber ein Paket.

~/src/mplayer-1.0-pre7$ dpkg-buildpackage -rfakeroot -uc -b


Im Prinzip kann man diese Vorgehensweise bei jedem Paket anwenden und somit den eigenen Ansprüchen gerecht werden.

Wie es explizit bei weiteren Distributionen ausschaut, kann ich leider nicht sagen.

[Rhönpaulus]

ich muß mplayer den pfad zum dvb-treiber mitgeben damit die treiberheader eingebunden werden können.
mit dem packetmanagment hatte ich keine probleme in der vergangenheit aber ich bin auch kein linuxprofi und habe nur erfahrungen mit redhat 7.1,7.2 und 9.0 gesammelt.
demnächst steige ich wegen einem festplattenschaden auf fc4 um.
rh9 ist mittlerweile wirklich etwas altbacken.

[Gast]

Schätzt man es dagegen Programme aus den Quellen zu bauen, fährt man IMO mit SuSIE den falschen Karren.


Warum?

Ich bau nun schon seit Jahren meine Pakete für SUSIE und bin happy damit. :-)

MfG,
P.

Anmerkung: Außerdem sollte man bei SUSE möglichst schnell auf apt umsteigen.
www.linux-club.de
Dort mal einen Blick in das APT-Forum werfen.

[Harleckin]

Anmerkung: Außerdem sollte man bei SUSE möglichst schnell auf apt umsteigen.
www.linux-club.de
Dort mal einen Blick in das APT-Forum werfen.
Dann nimm doch gleich das Original oder eines der Derivate.

[Gast]

Dann nimm doch gleich das Original oder eines der Derivate.

Warum?

[Harleckin]

Warum?
Warum auch nicht?

[Der Berater]

Weil man sich von seiner angestammten Distribution trennen müsste, ohne einen Mehrwert zu haben.
Ob ich nun apt als zusätzlichen Layer um dpkg oder rpm verwende, ist meines Erachtens relativ egal. Der Code von apt ist in beiden Fällen ein bescheidener Layer-over-Layer Hack, wie ein Blick auf den Sourcecode sehr deutlich zeigt.
Eigentlich bräuchte apt mal einen kompletten rewrite.

MfG,
P.