codecs auf Linux: Verzeichnisplatz (=?iso-8859-1?q?Verst=E4ndnisfrage?=)
Hallo Liste, ich versuche gerade herauszufinden, wie man auf einem Linux-System den Ort bestimmen kann, an dem die codecs für Audio- und Videodateien abgelegt sind. Bei der Installation von Xine habe ich gesehen, daß das benötigte W32-Paket einen Link in /usr/lib (codecs) anlegt, der auf das Verzeichnis /usr/lib/W32 verweist, in dem die Dateien untergebracht sind. Ich habe aber in /usr/lib noch zwei weitere Verzeichnisse gesehen, die solche Dateien enthalten. Wahrscheinlich würden bei selbst kompilierten Paketen die entsprechenden Daten in /usr/local/lib abzulegen sein. Wenn ich das jetzt richtig interpretiere, muß man unter Linux an verschiedenen Stellen (zumindest in den Verzeichnissen (mit Unterverzeichnissen) nach den installierten Codecs suchen. Das hieße für mich dann auch, daß jedes Abspielprogramm (wie auch Komprimierprogramm) sein eigenes Verzeichnis mit eigenen Codecs nutzen kann. Oder liege ich mit meiner Interpretation daneben? Vielen Dank für jeden Hinweis und schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
Am Dienstag, 4. Januar 2005 21:06 schrieb Andreas Mantke:
ich versuche gerade herauszufinden, wie man auf einem Linux-System den Ort bestimmen kann, an dem die codecs für Audio- und Videodateien abgelegt sind. Bei der Installation von Xine habe ich gesehen, daß das benötigte W32-Paket einen Link in /usr/lib (codecs) anlegt, der auf das Verzeichnis /usr/lib/W32 verweist, in dem die Dateien untergebracht sind.
Fast richtig, /usr/lib/win32 heißt das Verzeichnis, war lange der Standard für solche Libs (in dem übliche Multimedia-Programme gesucht haben), wurde aber von dem MPlayer Maintainer, der die Codecs dort betreut dann in /usr/lib/codecs umgeändert, da nicht nur Windows32, sondern auch binary Linux-Codecs (wie die vom RealPlayer) dort zu finden sind. Damit Programme nach altem und neuen Voreinstellungen die Codecs finden gibts nen Symlinc. Ihm wäre es sogar lieber gewesen, ich hätte die Codecs unter /usr/lib/codecs abgelegt und win32 als symlink angelegt (geht aber unter SuSE nicht, weil avifile das Verzeichnis schon mitbringt).
Ich habe aber in /usr/lib noch zwei weitere Verzeichnisse gesehen, die solche Dateien enthalten. Wahrscheinlich würden bei selbst kompilierten Paketen die entsprechenden Daten in /usr/local/lib abzulegen sein.
AFAIK gibt es kein im Source vorliegendes Programm, das seine Codecs in genanntem Verzeichnis ablegt. Es gibt auch keine einheitliche Codec Schnittstelle unter Linux, Du kannst also nicht avifile Dateiformate in MPlayer mitnutzen, oder MPlayer in xine oder ... Demzufolge bleibt das Binary-Treibern vorbehalten und wird bei einem Verzeichnis bleiben. Welche Verzeichnisse meinst Du da noch als zusätzlich?
Wenn ich das jetzt richtig interpretiere, muß man unter Linux an verschiedenen Stellen (zumindest in den Verzeichnissen (mit Unterverzeichnissen) nach den installierten Codecs suchen. Das hieße für mich dann auch, daß jedes Abspielprogramm (wie auch Komprimierprogramm) sein eigenes Verzeichnis mit eigenen Codecs nutzen kann. Oder liege ich mit meiner Interpretation daneben?
Liegst Du nicht ganz falsch. Jeder Player bringt normalerweise "seine codecs mit. Bei Avifile sind die schlicht in der /usr/lib/avifile-<version>, bei xine unter /usr/lib/xine/plugins/<version> und MPlayer hat alles in nem großen Binary. Andere Player machen es ähnlich, die die nen Wraper für Windows-Binary Codecs haben, schauen eben zusätzlich nach den Windows-DLLs (bei xine ist das Verzeichnis einstellbar, beim ersten Start wird automatisch gesucht) und die liegen halt für gewöhnlich in /usr/lib/win32 bzw. /usr/lib/codecs -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hallo, Am Donnerstag, 6. Januar 2005 01:19 schrieb Manfred Tremmel:
Liegst Du nicht ganz falsch. Jeder Player bringt normalerweise "seine codecs mit. Bei Avifile sind die schlicht in der /usr/lib/avifile-<version>, bei xine unter /usr/lib/xine/plugins/<version> und MPlayer hat alles in nem großen Binary. Andere Player machen es ähnlich, die die nen Wraper für Windows-Binary Codecs haben, schauen eben zusätzlich nach den Windows-DLLs (bei xine ist das Verzeichnis einstellbar, beim ersten Start wird automatisch gesucht) und die liegen halt für gewöhnlich in /usr/lib/win32 bzw. /usr/lib/codecs
Jetzt aber mal ne Frage: Wenn jeder Player seine Codecs selber basteln muss, dann muessen die als Source vorliegen. Gibt es da keine Copyright Probleme? Gruss Karl
Am Donnerstag, 6. Januar 2005 09:28 schrieb Karl Sinn:
Wenn jeder Player seine Codecs selber basteln muss, dann muessen die als Source vorliegen. Gibt es da keine Copyright Probleme?
Ja und nein. Die meisten Player bauen primär auf ffmpeg auf. Und die Projekte tauschen Programmcode aus, weshalb die Liste unterstützter Formate meist nicht zu weit voneinander abweicht. Natürlich gibt es bei diversen Formaten urheber- und patentrechtliche Probleme in unterschiedlichen Ländern. Dreimal darfst Du raten, warum Distributoren wie z.B. auch SuSE nur beschnittene Versionen mitliefert. Einer der Gründe, weshalb wir hier in Europa gut auf Softwarepatente verzichten können. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hallo Manfred, erst einmal vielen Dank für die Antwort. Am Donnerstag, 6. Januar 2005 01:19 schrieb Manfred Tremmel:
Am Dienstag, 4. Januar 2005 21:06 schrieb Andreas Mantke: (...)
Fast richtig, /usr/lib/win32 heißt das Verzeichnis, war lange der
stimmt. Ich brauche wohl 'ne Brille oder die Tastatur prellt ;-) (...)
Ich habe aber in /usr/lib noch zwei weitere Verzeichnisse gesehen, die solche Dateien enthalten. Wahrscheinlich würden bei selbst kompilierten Paketen die entsprechenden Daten in /usr/local/lib abzulegen sein.
AFAIK gibt es kein im Source vorliegendes Programm, das seine Codecs in genanntem Verzeichnis ablegt. Es gibt auch keine
Damit scheidet dann ein Verzeichnis mit Unterverzeichnissen schon einmal aus. Allerdings bleiben immer noch genug Orte für Codecs übrig.
einheitliche Codec Schnittstelle unter Linux, Du kannst also nicht avifile Dateiformate in MPlayer mitnutzen, oder MPlayer in xine oder ...
Geht das denn in einer anderen Systemumgebung? Ich vermute mal, daß RealPlayer unter Win das auch nicht tut; zumal das Dateiformat auch ein anderes ist (wobei ich jetzt wieder Feuer und Wasser vergleiche).
Demzufolge bleibt das Binary-Treibern vorbehalten und wird bei einem Verzeichnis bleiben. Welche Verzeichnisse meinst Du da noch als zusätzlich?
Ich habe noch das Verzeichnis RealPlayer8/Codecs und das avifile0.7 gefunden, das Du angesprochen hast. Ob libquicktime auch welche enthält, weiß ich jetzt nicht.
Wenn ich das jetzt richtig interpretiere, muß man unter Linux an verschiedenen Stellen (zumindest in den Verzeichnissen (mit Unterverzeichnissen) nach den installierten Codecs suchen. Das hieße für mich dann auch, daß jedes Abspielprogramm (wie auch Komprimierprogramm) sein eigenes Verzeichnis mit eigenen Codecs nutzen kann. Oder liege ich mit meiner Interpretation daneben?
Liegst Du nicht ganz falsch. Jeder Player bringt normalerweise
Im Windows-System sollen auch keine Codecs aus verschiedenen Quellen gemischt werden.
"seine codecs mit. Bei Avifile sind die schlicht in der /usr/lib/avifile-<version>, bei xine unter /usr/lib/xine/plugins/<version> und MPlayer hat alles in nem großen Binary. Andere Player machen es ähnlich, die die nen Wraper für Windows-Binary Codecs haben, schauen eben zusätzlich nach den Windows-DLLs (bei xine ist das Verzeichnis einstellbar, beim ersten Start wird automatisch gesucht) und die liegen halt für gewöhnlich in /usr/lib/win32 bzw. /usr/lib/codecs
Das macht die Angabe dazu, wo man bei einem Linux-System schauen muß, um die vorhandenen Codecs (auf diesem System) zu identifizieren, nicht gerade einfach. Im Windows-System ist das insoweit einfacher festzustellen. Aber dafür gibt es da auch mehr Monokultur und man kann nicht einfach den Player wechseln. Noch eine weitere Verständnisfrage: Das Dateiformat (z.B. avi) ist als Container zu sehen, in dem dann letztlich der mit dem Komprimier-Dekomprimier-Algorithmus erstellte Inhalt steckt. D.h., auch wenn es nach außen hin ein avi-file ist, kann innen drin völlig anderer Inhalt stecken (mit unterschiedlicher Art und Weise des Komprimierungsverfahrens) und deshalb nur auf dem System abspielbar sein, das den entsprechenden Codecs bereit stellt. So habe ich jedenfalls die Infos verstanden, die ich dazu gelesen habe. Schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
Am Donnerstag, 6. Januar 2005 18:59 schrieb Andreas Mantke:
Hallo Manfred,
einheitliche Codec Schnittstelle unter Linux, Du kannst also nicht avifile Dateiformate in MPlayer mitnutzen, oder MPlayer in xine oder ...
Geht das denn in einer anderen Systemumgebung? Ich vermute mal, daß
Gute Frage, beim Amiga gabs DataTypes, die Systemweit Dateiformate bekannt gemacht haben (Bilder-, Audio-, Video-, Hypertext- und weiß der Geier was für Formate noch alles). Nach Installation eines DataTypes konnten dann alle Programme mit dem Format umgehen, die die DataType Schnittstelle verwendeten.
RealPlayer unter Win das auch nicht tut; zumal das Dateiformat auch ein anderes ist (wobei ich jetzt wieder Feuer und Wasser vergleiche).
Ich kenne Windowsinterna zu wenig um beurteilen zu können, wie das da abläuft. Ich hatte nie eins und kann auch gut verzichten.
Ich habe noch das Verzeichnis RealPlayer8/Codecs und das avifile0.7 gefunden, das Du angesprochen hast. Ob libquicktime auch welche enthält, weiß ich jetzt nicht.
Ok.
Das macht die Angabe dazu, wo man bei einem Linux-System schauen muß, um die vorhandenen Codecs (auf diesem System) zu identifizieren, nicht gerade einfach. Im Windows-System ist das insoweit einfacher festzustellen. Aber dafür gibt es da auch mehr Monokultur und man kann nicht einfach den Player wechseln.
Hat alles seine Vor- und Nachteile.
Noch eine weitere Verständnisfrage: Das Dateiformat (z.B. avi) ist als Container zu sehen, in dem dann letztlich der mit dem Komprimier-Dekomprimier-Algorithmus erstellte Inhalt steckt. D.h., auch wenn es nach außen hin ein avi-file ist, kann innen drin völlig anderer Inhalt stecken (mit unterschiedlicher Art und Weise des Komprimierungsverfahrens) und deshalb nur auf dem System abspielbar sein, das den entsprechenden Codecs bereit stellt. So habe ich jedenfalls die Infos verstanden, die ich dazu gelesen habe.
Ich kann da nur zu xine ins Detail gehen. Es gibt da verschiedene Verarbeitungsstufen: 1. Input-Plugin liest die Daten über diverse Quellen (http, file, ...) 2. Demuxer ist für die Erkennung und Bearbeitung des Containerformats zuständig (AVI, Quicktime, ...), er extrahiert daraus die einzelnen Informationen wie Ton und Audiospur heraus. 3. Audio-/Video-Codec, decodiert Audio- bzw. Videodaten 4. Audio-/Video-Ausgabeplugin ist für die Darstellung bzw. Soundausgabe zuständig -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Hallo Manfred, nochmals danke für Deine Antwort. Am Donnerstag, 6. Januar 2005 21:29 schrieb Manfred Tremmel:
Am Donnerstag, 6. Januar 2005 18:59 schrieb Andreas Mantke:
Hallo Manfred,
einheitliche Codec Schnittstelle unter Linux, Du kannst also nicht avifile Dateiformate in MPlayer mitnutzen, oder MPlayer in xine oder ...
Geht das denn in einer anderen Systemumgebung? Ich vermute mal, daß
Gute Frage, beim Amiga gabs DataTypes, die Systemweit Dateiformate bekannt gemacht haben (Bilder-, Audio-, Video-, Hypertext- und weiß der Geier was für Formate noch alles). Nach Installation eines DataTypes konnten dann alle Programme mit dem Format umgehen, die die DataType Schnittstelle verwendeten.
Das wäre für die Zukunft eine gute Perspektive, wenn man sich auf ein gemeinsames Format der Codecs einigen könnte und alle Programme dann dadrauf zugreifen könnten. Das m.E. wäre ein entscheidender Vorteil auch gegenüber anderen Betriebssystemen. (...)
Ich kenne Windowsinterna zu wenig um beurteilen zu können, wie das da abläuft. Ich hatte nie eins und kann auch gut verzichten.
Da könnte ich gut drauf verzichten. Aber ich muß mich im Moment mit beiden Systemen auseinander setzen. Und manche Sachen, die ich gerade ausprobiere laufen - nach dem was ich feststellen mußte - nur unter Windows und scheinen für Linux noch nicht fertig zu sein. Aber nach dem was ich gelesen habe, kann man unter Win auch nicht Codecs aus mehreren Quellen benutzen.
Ich habe noch das Verzeichnis RealPlayer8/Codecs und das avifile0.7 gefunden, das Du angesprochen hast. Ob libquicktime auch welche enthält, weiß ich jetzt nicht.
Ok.
Das heißt, daß in libquicktime auch welche enthalten sind? (...)
Noch eine weitere Verständnisfrage: Das Dateiformat (z.B. avi) ist als Container zu sehen, in dem dann letztlich der mit dem Komprimier-Dekomprimier-Algorithmus erstellte Inhalt steckt. D.h., auch wenn es nach außen hin ein avi-file ist, kann innen drin völlig anderer Inhalt stecken (mit unterschiedlicher Art und Weise des Komprimierungsverfahrens) und deshalb nur auf dem System abspielbar sein, das den entsprechenden Codecs bereit stellt. So habe ich jedenfalls die Infos verstanden, die ich dazu gelesen habe.
Ich kann da nur zu xine ins Detail gehen. Es gibt da verschiedene Verarbeitungsstufen:
1. Input-Plugin liest die Daten über diverse Quellen (http, file, ...) 2. Demuxer ist für die Erkennung und Bearbeitung des Containerformats zuständig (AVI, Quicktime, ...), er extrahiert daraus die einzelnen Informationen wie Ton und Audiospur heraus. 3. Audio-/Video-Codec, decodiert Audio- bzw. Videodaten 4. Audio-/Video-Ausgabeplugin ist für die Darstellung bzw. Soundausgabe zuständig
Danke für die konkrete Erklärung. Dann habe ich das, was ich gelesen habe, richtig interpretiert. Dann habe ich jetzt das richtige Bild davon. Schönen Abend Andreas -- ## Content Developer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.amantke.de
Am Donnerstag, 6. Januar 2005 22:12 schrieb Andreas Mantke:
Hallo Manfred,
nochmals danke für Deine Antwort.
Am Donnerstag, 6. Januar 2005 21:29 schrieb Manfred Tremmel:
Am Donnerstag, 6. Januar 2005 18:59 schrieb Andreas Mantke:
Hallo Manfred,
einheitliche Codec Schnittstelle unter Linux, Du kannst also nicht avifile Dateiformate in MPlayer mitnutzen, oder MPlayer in xine oder ...
Geht das denn in einer anderen Systemumgebung? Ich vermute mal, daß
Gute Frage, beim Amiga gabs DataTypes, die Systemweit Dateiformate bekannt gemacht haben (Bilder-, Audio-, Video-, Hypertext- und weiß der Geier was für Formate noch alles). Nach Installation eines DataTypes konnten dann alle Programme mit dem Format umgehen, die die DataType Schnittstelle verwendeten.
Das wäre für die Zukunft eine gute Perspektive, wenn man sich auf ein gemeinsames Format der Codecs einigen könnte und alle Programme dann dadrauf zugreifen könnten. Das m.E. wäre ein entscheidender Vorteil auch gegenüber anderen Betriebssystemen.
Ja, das war (ist) einfach genial. PPaint/Photogenics... können das XYZ-Format nicht? Datatype aus dem Aminet holen, 3-4 Dateien an die richtige Stelle kopieren. Fertig, Dateiformat bekannt. Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
Hallo, Am Donnerstag, 6. Januar 2005 18:04 schrieb Manfred Tremmel:
Ja und nein. Die meisten Player bauen primär auf ffmpeg auf. Und die Projekte tauschen Programmcode aus, weshalb die Liste unterstützter Formate meist nicht zu weit voneinander abweicht. Natürlich gibt es bei diversen Formaten urheber- und patentrechtliche Probleme in unterschiedlichen Ländern. Dreimal darfst Du raten, warum Distributoren wie z.B. auch SuSE nur beschnittene Versionen mitliefert.
Warum haben die Leute von SuSE ein Problem damit, und die Leute von z.B.: Packman nicht? Gruss Karl
Am Donnerstag, 6. Januar 2005 23:42 schrieb Karl Sinn:
Hallo,
Am Donnerstag, 6. Januar 2005 18:04 schrieb Manfred Tremmel:
Ja und nein. Die meisten Player bauen primär auf ffmpeg auf. Und die Projekte tauschen Programmcode aus, weshalb die Liste unterstützter Formate meist nicht zu weit voneinander abweicht. Natürlich gibt es bei diversen Formaten urheber- und patentrechtliche Probleme in unterschiedlichen Ländern. Dreimal darfst Du raten, warum Distributoren wie z.B. auch SuSE nur beschnittene Versionen mitliefert.
Warum haben die Leute von SuSE ein Problem damit, und die Leute von z.B.: Packman nicht?
Die von suSE (...) Verdienen GELD damit... und da könnte es durchaus mal sein daß einer von denen (...) mal dummerweise in die USA kommt..... ;-)))) MfG Tb -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Am Donnerstag, 6. Januar 2005 23:51 schrieb Karl Sinn:
Am Freitag, 7. Januar 2005 00:08 schrieb Thilo Alfred Bätzig:
Die von suSE (...) Verdienen GELD damit... und da könnte es durchaus mal sein daß einer von denen (...) mal dummerweise in die USA kommt..... ;-))))
Und? Ich verstehe den Zusammenhang nicht?
Mannnn das war n Gag Du wirst aber z.B. bei Packman aus eben diesem Grund kein fertig funktionstüchtiges Packet für decss bekommen (Aber eine Anleitung wie man sich dieses Zeug im Quelltext holt und richtig Installiert) unnd da man ja in anderen Ländern mit anderen Rechtsvorschriften zu Kämpfen hat, und suSe Ihre Boxen auch ausserhalb Deutschlands verkaufen möchten, sind die SuSE Pakete under anderem auch (ein kleinwenig) darauf geprüft wie weit Konflikte entstehen können. und es liegt in der Natur der Sache daß Packman zum jetzigen Zeitpunkt keine Distribution auf der ganzen Welt verfolgt, und daher auch nicht zwingend auf die Wirren Patentfolterungen anderer Länder achten muß. (Wenn Packmänner aufgrund von Auslieferungsabkommen, eingesperrt werden, haben wir dann auch ganz andere Probleme, als Funktionierende Hardware) BTW dieser Gag von mir oben war doch eigentlich leicht zu durchsehen, wenn Du schwerverdauliches haben willst.... dann hilft evtl SuSe Talk weiter hehe MfG Tb -- http://www.gasthof-linde.de http://www.chef-de-cuisine.de
Am Donnerstag, 6. Januar 2005 23:42 schrieb Karl Sinn:
Warum haben die Leute von SuSE ein Problem damit, und die Leute von z.B.: Packman nicht?
SuSE ist ein kommerzieller Distributor, der seine Pakete in diversen Ländern verkauft. Da fließt Geld, da kann man was holen mit ner Klage. Packman ist eine nichtkommerzielle Webseite, falls man die verklagt, ist kein Geld zu holen, höchstens die Einstellung der Seite. Außerdem findet kein Vertrieb im eigentlichen Sinne statt und es findet alles in Deutschland statt (wo es bisher ja glücklicherweise keine Softwarepatente gibt) und demzufolge die hiesige Rechtssprechung die Basis bildet (nicht dass man sich auf sowas verlassen kann, aber ...). SuSE hingegen muss auf die Rechtslage in allen Vertriebsländern Rücksicht nehmen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Donnerstag, 6. Januar 2005 22:12 schrieb Andreas Mantke:
Hallo Manfred, ...
Gute Frage, beim Amiga gabs DataTypes, die Systemweit Dateiformate bekannt gemacht haben (Bilder-, Audio-, Video-, Hypertext- und weiß der Geier was für Formate noch alles). Nach Installation eines DataTypes konnten dann alle Programme mit dem Format umgehen, die die DataType Schnittstelle verwendeten.
Das wäre für die Zukunft eine gute Perspektive, wenn man sich auf ein gemeinsames Format der Codecs einigen könnte und alle Programme dann dadrauf zugreifen könnten. Das m.E. wäre ein entscheidender Vorteil auch gegenüber anderen Betriebssystemen.
Ich fand es genial, Devs/DataTypes enthielt eine Datei, die zur Identifikation des Formats verwendet wurde (demuxer) und Classes/DataTypes für die eigentliche Arbeit (codec). Gibt noch einige interessante Sachen beim Amiga, die ich so noch auf keinem anderen System gesehen habe.
Das heißt, daß in libquicktime auch welche enthalten sind?
Das letzte mal, dass ich mir die libquicktime angesehen habe, war die Codecunterstützung sehr dürftig, aber so wie es aussieht sind die Codecs zur libquicktime unter /usr/lib/libquicktime/ zu finden. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
participants (5)
-
Andreas Mantke -
Karl Sinn -
Manfred Tremmel -
Michael Hoehne -
Thilo Alfred Bätzig