Re: audio/clementine-player

From: Polytropon <freebsd(at)edvax.de>
Date: Wed, 28 Dec 2011 14:53:15 +0100

On Wed, 28 Dec 2011 14:13:34 +0100 (CET), Oliver Fromme wrote:
> Polytropon <freebsd(at)edvax.de> wrote:
> > In den Dateinamen sieht man solche Informationen meist
> > nicht, die heißen dann .avi oder .mp4; erst Tests wie
> > "mplayer -identify <Datei>" bringen den konkreten Inhalt
> > (d. h. seine Formate) ans Licht.
>
> Häufig nützt auch schon ein banales »file <Datei>«:
>
> $ file foo.avi
> foo.avi: RIFF (little-endian) data, AVI, 720 x 576, 25.00 fps,
> video: XviD, audio: Dolby AC3 (6 channels, 48000 Hz)

Stimmt, gerade geprüft - "file" ist da schon sehr
hilfreich und gehört im Gegensatz zu mplayer zum
Betriebssystem. :-)

> Und bei manchen Containerformaten ist es eh relativ trivial,
> in einem DVD-ISO kann z.B. nur MPEG2 als Video drin sein (gut,
> für's Audio gibt es mehrere Möglichkeiten, aber immerhin kein
> Vorbis).

Es sei denn, es ist ein "Daten-DVD-ISO, weil der DVD-
Player ja auch so Dateien abspielt", dann kann wieder
_alles_ drin sein.

> > Für Ogg/Vorbis (Audio) heißen die Dateien meist .ogg,
> > für Ogg/Theora (Video) oft .ogv oder .ogm, wenn ich das
> > richtig in Erinnerung habe. Sieht aber nicht sehr logisch
> > aus, weswegen ich dannehme, daß ich mich hier irre. :-)
>
> Ja, das hat historische Gründe (wie so viele Fehler, mit
> denen man heute leben muss). Ursprünglich gab es nur Ogg-
> Vorbis, und es hatte sich der Einfachheit halber einge-
> bürgert, die Dateien .ogg zu nennen. Aus heutiger Sicht
> war das keine optimale Idee. Später kam dann Theora als
> Video-Codec dazu, und seitdem haben wir den Kuddelmuddel.

Man könnte sich ja eine vernunftbasierte Namenskonvention
angewöhnen, dann kann es aber passieren, daß es bei
weniger intelligenten Systemen zu Schwierigkeiten bei
der Interpretation kommt, z. B. Ogg/Vorbis = ogv oder
oga (für "audio"), Ogg/Theora = ogt oder ogv (für "video")...

> Auch beim sogenannten "mp3" (eigentlich keine offizielle
> Bezeichnung, geschweige denn ein Dateiformat) ist es so.

Und dennoch hat sich diese Ungenauigkeit durchgesetzt.
Bei mehr oder minder starken Abweichungen bei der
Implementierung kriegt man dann den Spaß bei den
Endgeräten, die es "sehr genau" nehmen.

> > Persönlich finde ich es praktisch, bei Medienwieder-
> > gabeprogrammen immer _alles_ and Codecs zu installieren,
> > dann kommt man nicht in die Petrullje, daß irgend etwas
> > mal _nicht_ abgespielt werden kann. Das ist allerdings
> > nicht der Default-Zustand, was wiederum andere Benutzer
> > freut, die sich eben nicht beladen wollen mit Codecs
> > und Containern, die sie ihr Lebtag nicht brauchen oder
> > ausdrücklich nicht wollen.
>
> Ja. Idealerweise sollte das Ports-Framework die Bedürfnisse
> aller Benutzer befriedigen. Wer sich auskennt und sich die
> Codecs aussuchen möchte, sollte das explizit tun können, und
> wer das nicht will, sollte einfach "alle" anklicken können,
> oder so ähnlich.

Leider fingert hier die Dummheit aus dem Bereich
der Juristerei hinein. Wie schön wäre es, könnte
man einfach "pkg_add -r mplayer" machen, und man
bekommt mplayer + mencoder mit _allen_ Codecs. Nur
ist MP3 oder VPX "illegal" in manchen Ländern, so
daß hier nur der Griff zur Makefile.local und der
Ports-Infrastruktur das gewünschte Ergebnis liefert.
So ein Port, meinetwegen "mplayer-full" wäre schon
recht praktisch, vor allem, wenn man ältere Mit-
bürger, äh Mitrechner noch produktiv verwenden
möchte. :-)

> Ich persönlich installiere normalerweise nur Codecs, von
> denen ich weiß, dass ich sie brauche (oder mit einer gewissen
> Wahrscheinlichkeit brauchen könnte). Zum einen hält das das
> System schlanker, reduziert die Anzahl der Dependencies und
> macht Updates leichter und schneller. Zum anderen binde ich
> mir nicht unnötig Sicherheitslücken ans Bein. Es gibt ja
> durchaus alle naselang Exploits für irgendwelche Multimedia-
> formate.

Das ist ein durchaus gerechtfertigter Punkt, der
der eierlegenden Wollmichsau entgegensteht. Die
Ports Collection hilft ja auch hier sinnvoll weiter.

Würde man für n Optionen vorcompilierte Pakete
bereitstellen wollen, würde das in 2 x 2^n + x
Paketen ausarten (+x wegen CFLAGS). Von der
Reihenfolge der Optionennennung in den Paketnamen
will ich gar nicht erst anfangen, exponentiellen
Aufwand meide ich wie die Pest. :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 28 Dec 2011 - 14:53:25 CET

search this site