Klicke HIER für Netscape 4.x- und IE-verträgliche Webseiten.

training bildTraining & Anleitungen

OGG machen auf Linux

In dieser Bedienanleitung, hier 'manual' genannt, wird erklärt, wie fertig bearbeitete Videoclips in das OGG-Format umgewandelt werden können. Die Videospur wird dabei als Theora-, die Audiospur als Vorbis-Codec in einem OGG genannten Container (synonym für Format) gespeichert. Dazu stehen unterschiedliche Methoden zur Verfügung. Eine Software funtioniert sogar auf allen drei üblichen Betriebssystemen (linux, mac und gates): ffmpeg2theora. Im folgenden wird Installation und Handhabung dieses Konsolenprogramms für eine linux-Plattform beschrieben. Die Handhabung ist also auch auf die anderen Betriebssysteme übertragbar, grundsätzlich.

Schritt 1: Programm besorgen, entpacken und starten

Obwohl ich ffmpeg2theora eigentlich anders installieren wollte, habe ich jetzt auf linux die Windowswelt approximiert durch Benutzen des bereits kompilierten Programms. Das sollte dann in etwa mit dem ffmpeg2theora*.exe vergleichbar sein (Version: http://www.v2v.cc/~j/ffmpeg2theora/ffmpeg2theora-0.18.exe).

Ich habe als normaler user das aktuelle binary von http://www.v2v.cc/~j/ffmpeg2theora/download.html geladen. Heute (15mrz07) wurde offeriert ffmpeg2theora-0.18 der Ordnung halber wurde das Programm in das Verzeichnis ffmpeg2theora entpackt.

[blutsvente@pippi ~]$ mkdir ffmpeg2theora
[blutsvente@pippi ~]$ cd ffmpeg2theora
[blutsvente@pippi ffmpeg2theora]$ wget http://www.v2v.cc/~j/ffmpeg2theora/ffmpeg2theora-0.18.linux.bin.bz2

Selbstredend kann das Programmpaket auch mit anderen Verfahren geladen werden.

Jetzt auspacken und anschauen:

[blutsvente@pippi ffmpeg2theora]$ bunzip2 ffmpeg2theora-0.18.linux.bin.bz2
[blutsvente@pippi ffmpeg2theora]$ ll
total 7316 -rw-rw-r-- 1 blutsvente blutsvente 7475548 Nov 21 23:42 ffmpeg2theora-0.18.linux.bin

Aha, die Datei ist noch nicht ausführbar, also noch schnell ein chmod :

[blutsvente@pippi ffmpeg2theora]$ chmod 755 ffmpeg2theora-0.18.linux.bin

aus reiner bequemlichkeit setze ich auch noch einen alias in die Datei ~/.bashrc, denn wer will schon immer die Buchstabenwurst ffmpeg2theora eintippen. Die einzufügende Zeile sieht in meinem Fall so aus:

alias ff2t='/home/blutsvente/ffmpeg2theora/ffmpeg2theora-0.18.linux.bin'

Und schon geht es los. Nur man-pages gibt es nicht, dafür spuckt das Programm bei argumentfreiem Programmaufruf alle möglichen Optionen aus. Vorher wechsel ich jedoch in das Videoverzeichnis, damit alles schön sortiert bleibt ;-)

[blutsvente@pippi ffmpeg2theora]$ cd ../video
[blutsvente@pippi video]$ ff2t

Jetzt ist Zeit für eine gute Tasse Kaffee oder Tee. Schön lesen bzw. rtfm! Hinweise und ein paar Beispiele gibt es im nächsten Schritt. Let's go.

Schritt 2: Kodieren

Input

Der fertige Videoclip liegt als DV-codierte Datei vor. Das Konvertierungstool ffmpeg2theora frisst eine Vielzahl von Eingabecodecs und -formaten. Das Dateiformat kann AVI oder Quicktime/MOV sein, das Video ist dv1, dv2 oder dv2openDML. Audio ist ein PCM-Signal. Zumindest bei meinen Tests haben diese Codec-Format-Kombinationen keine Probleme gemacht.

Als praxisnahes Beispiel diene im Folgenden ein Clip der Länge 213 Sekunden bzw. 3 Minuten und 33 Sekunden. Der Clip mit Namen Clowns macht es dem Codieralgorithmus nicht einfach: harte Schnitte von hell zu dunkel und umgekehrt, schnelle Schwenks und Zooms, Bewegung im Bildhintergrund bei ruhigem Vordergrund usw. etc. Kurzum: wie im richtigen Leben. Hier noch die entsprechenden Daten:

Name: clowns-dv.avi 
VIDEO:  [dvsd]  720x576  24bpp  25.000 fps  28800.0 kbps (3515.6 kbyte/s)
AUDIO: 48000 Hz, 2 ch, s16le, 1536.0 kbit/100.00% (ratio: 192000->192000)
Dateigröße:  808589076 Byte

Die "Hausnummer" beträgt also ungefähr 3700 kilobyte pro Sekunde - komprimieren ist offensichtlich nötig.

Allgemeine Hinweise

Zunächst noch ein paar grundsätzliche Anmerkungen:

  1. Durch Festlegung der Videobitrate (auf der Kommandozeile -V bzw. --videobitrate) wird die DURCHSCHNITTLICHE Bitrate bestimmt bzw. angestrebt. Diese schwankt je nach Videomaterial. Eine Qualitätsfestlegung (auf der Kommandozeile -v bzw. --videoquality) ist für unsere Zielsetzung nach meiner Einschätzung ungeeignet.
  2. Wenn die Videodatei nicht direkt gestreamt wird, unbedingt die Option “--optimize” nutzen. Das verändert bei Bestimmung der durchschnittlichen Bitrate nicht die Dateigröße, verbessert aber die Qualität. (Wenn die Qualität mittels der “--videoquality”-Option festgelegt wird, wird die Datei kleiner.)
  3. Die Videobildgröße hat naturgemäß Einfluss auf den Umfang der Datei, jedoch sind Daumenkinos für DSL2000-Downloads nicht nötig. Derzeit gängig sind Videos mit 320x240 Pixel und mit 384x288 Pixel. Ich finde letztere Größe schick und ausreichend, wenn ich Videos auf dem Rechner gucke. Bei Talking-Heads-Videomaterial geht eventuell auch 512x384 bei selber Dateigröße, es bewegt sich ja nur der Mund: auf und zu und auf und zu...
  4. Das DV-Rohmaterial hat 25 Bilder pro Sekunde. Falls bleeding Bruce Willis nicht wild durchs Video springt lässt sich daran auch rumschrauben. Die letzten bei KanalB plazierten Clips habe ich mit 20 Bildern pro Sekunde (englisch: frames per second, fps) kodiert. Sind ja immerhin fünf Bilder weniger, anders ausgedrückt: eine Reduktion um 5/25 = 20 %. Okay, da ist das Milchmädchen nicht weit, aber die Idee ist deutlich geworden, oder?
  5. Das Audiosignal lässt sich wunderbar schrumpfen. Der VORBIS-Codec ist diesbezüglich wirklich charmant. Solange keine Musikvideos produziert werden, stattdessen gesprochenes Wort und Demogeräusche die Soundkulisse abgeben, reicht eine Abtastrate von 22050 Hertz bei 48 Kilobit/Sekunde. Hier kann auch gerne mit der Audioqualitätsoption (auf der Kommandozeile -a bzw. --audioquality) rumgespielt werden. Ebenso liesse sich überlegen, ob das Signal unbedingt Stereo sein muss oder Mono ausreicht. Da lässt sich zwar nicht viel Datensalat sparen, aber Kleinvieh...

Kodieren mit v2v-Voreinstellungen

Eine opulent-gigantische OGG-Datei ist durch Anwendung des von v2v (http://v2v.cc (externer Link)) ersonnenen und konsequent empfohlenen 'preview'-Profils für ffmpeg2theora entstanden, also als Kommandozeile

[blutsvente@pippi video]$ ff2t -p preview clowns-dv.avi 

Erzeugt wird im selben Verzeichnis die Datei mit Namen clowns-dv.ogg. Diese ist 39 Megabyte groß. Die Videoqualität ist selbstredend gut, nein: sehr gut! Nur sind diese 11 Mbyte/min als download file einfach kackendreist. Ein mit der preview Option gerenderter Film in üblicher Spielfilmlänge übersteigt die Speicherkapazität einer CDRom – und das dann durchs Netz. Bei dem erwartbaren Datenverkehr (Traffic) würden wir uns selbst kostbare Bandbreite nehmen und kurzsaugende downloader vom schnellen Clipzappen abhalten - Punkt :-) (rechnerische download-Zeiten lassen sich bspw. auf http://www.dsl-rechner.de (externer Link) ermitteln - das tool schick.)

Was genau bewirkt die 'preview'-Einstellung? Die Konsoleneingabe

[blutsvente@pippi video]$ ff2t -p info

erzeugt die Ausgabe:

v2v presets:
preview        Video: 320x240 if fps ~ 30, 384x288 otherwise
Quality 5 - Sharpness 2
Audo: Max 2 channels - Quality 1

Die Audiospur ist mit 48 kHz abgetastet worden. Das Profil 'preview' übersetzt in Kommandozeilensprech lautet somit:

[blutsvente@pippi video]$ ff2t -x 384 -y 288 -v 5 -a 1 clowns-dv.avi

Mit der Option --optimize kann die Dateigröße in diesem Fall um 958 Kilobyte reduziert werden, also um etwa 2,5 % der vorherigen preview-Größe. Allerdings benötigt der Encodiervorgang dann länger. Solange Zeit kein Problem darstellt im Produktionsprozess, und bei kurzen Clips handelt es sich wirklich nur um einige Minuten mehr oder weniger, ist die Optimierungsoption bei mir Standard. Für livestreaming hingegen ist Verzicht die klügere Strategie.

Kodieren mit Kompromissen I - ready for screening?

Es gibt bei dezentraler 'Redaktionsstruktur' allgemein zwei Engpässe bei der Datenübertragung durch das Netz bzw. Internet: Flaschenhals Nummer eins ist die 'upload'-Bandbreite, durch die eine Videogruppe ihren frisch geschnittenen (und sauber verpixelten) Clip auf die Website schieben kann. Der zweite Engpass wird i.d.R. die Netzanbindung des 'download'-Rechners sein. Hier gilt es, die Ladezeiten erträglich zu halten. Naturgemäß haben auch Serverbandbreiten Grenzen. Bei kurzen Clips von etwa 2 bis 9 Minuten Dauer halte ich eine Download/Clipdauer-Verhältnis von 1 bis maximal 1,5 für akzeptabel, so der Clip dann auch in annehmbarer Qualität und Größe betrachtet werden kann. Das ist für user wie mich okay, so lässt sich ein wenig zappen (quasi-zappen), ohne die Augen zu beleidigen. Diese youtube-Artefaktshow ist nicht wirklich erträglich, oder? Als Referenz dient mir die durchschnittliche download-Rate eine DSL2000-Anschlusses: etwa (bei rechnerischen 2048 kbit/s downstream, 192 kbit/s upstream) 500 bis 600 kbit/s sollten vom download client möglich sein (und auch als upload erträglich?).

Für die Audiospur reichen meist 48 Kilobit pro Sekunde, Stereo oder Mono, bei 22050 Hertz. Es geht oftmals noch kleiner, ohne dass die Sprachverständlichkeit darunter leidet; der Ton wird etwas 'dünner'. Damit verbleiben zwischen 450 und 550 kbit/s für den Videostream. Dann fangen wir mal an zu rechnen...

[hier kommt noch code rein]

Kodieren mit Kompromissen II - winzigkleine OGGs

Es lassen sich durchaus ansehnliche OGG-Dateien mit 250 kbit/s (Video und Audio!) und einer Auflösung von 320 zu 240 Pixeln generieren. Solcherlei Größen waren vor DSL etwa auf kanalB.de üblich und anempfohlen. Nur werden sie bislang (zu) oft mit Realmedia-Dateien (RM) oder flash-Filmen besetzt. Mit den folgenden Einstellungen habe ich ein ausreichendes RM-Surrogat hergestellt:

[blutsvente@pippi video]$ ff2t --optimize -V 200 -F 20 -x 320 -y 240 -A 32\
 -c 1 -H 22050 -o output.ogg input-dv-avi

Die Option -F legt die Anzahl der Bilder pro Sekunde (frames per second) fest. Die vergleichbaren Realmedia-Dateien haben fps zwischen 16 und 20. Die Bildqualität ist genauso akzeptabel oder inakzeptabel wie diejenige des Realmedia-Videoa.