Zockertown: Nerten News

Hallo alle,

in dieser Ausgabe will ich nur ein Beispiel zeigen,  wie man Skypegespräche aufzeichnen kann. Es wird natürlich mit auch anderen Programmen funktionieren.

Dies mal müssen wir ein wenig Pusleaudiomagie nutzen. Als ersten müssen wir das aufzeichnen können, was unser PC ausgibt. Wir brauchen einen Monitor des Audioausgangs:

pactl list | grep Name | grep monitor 
   Name: alsa_output.pci-0000_00_1b.0.analog-stereo.monitor
   Name: combined.monitor

Bei mir sind es zwei, in der Regel sollte es ein ALSA Gerät sein...  "alsa_output.pci-0000_00_1b.0.analog-stereo.monitor".

Lass uns jetzt etwas damit aufnehmen:

gst-launch pulsesrc device=alsa_output.pci-0000_00_1b.0.analog-stereo.monitor ! vorbisenc ! oggmux ! filesink location=out.ogg

Wir wollen aber einen Gespräch aufnehmen, also wir brauchen nicht nur einen Ausgang sondern auch einen Eingang und zwar zusammen gemischt.  Dafür brauchen wir ein adder Element:

gst-launch adder name=mix ! audioconvert ! vorbisenc ! oggmux ! filesink location=out.ogg
pulsesrc device=alsa_output.pci-0000_00_1b.0.analog-stereo.monitor ! queue ! mix. 
pulsesrc ! queue ! mix.

In diesem Beispiel habe ich mit dem Ausgang (SINK) angefangen. Jeder mix. wird dann auf adder weiter leiten (ich hoffe es ist nicht zu  verwirrend). Der erste pulsesrc nimmt den Monitor auf. Der zweite pulsesrc zeichnet das Default Aufnahmegerät auf. Dann alles wird mit adder gemischt, mit vorbisenc encodiert, in ogg reingestopft, und in eine Datei gespeichert.

Um besser zu verstehen wie Elemente im Gstreamer funktionieren, muss man noch ein paar Worte über SRC und SINK sagen.

Die meisten Elemente  haben Eingang und Ausgang. Es kommt dabei ständig zur Verwirrungen: was Ausgang (SRC) und was Eingang (SINK) ist. Am einfachsten ist es im bezug zu anderen Element zu verstehen, hier ist ein Beispiel:

[Element 1]--src-->>--sink--[Element 2]--src-->>--sink--[Element 3]

Und so weiter. Nur ein passende SINK kann zu einem SRC eingeschlossen. Lasst uns  pulsesrc nehmen. Dieses Element hat nur SRC (natürlich im begrenzten Sinne für Gstreamer). Jetzt schauen wir in die Beschreibung von pulsesrc:

gst-inspect pulsesrc

Factory Details:
  Long name:    PulseAudio Audio Source
  Class:    Source/Audio
  Description:    Captures audio from a PulseAudio server
  Author(s):    Lennart Poettering
  Rank:        primary (256)
...

Pad Templates:
  SRC template: 'src'
    Availability: Always
    Capabilities:
      audio/x-raw-int
             endianness: { 1234, 4321 }
                 signed: true
                  width: 16
                  depth: 16
                   rate: [ 1, 2147483647 ]
               channels: [ 1, 32 ]

Die wichtige Teil für uns fängt mit den Worten SRC template an. Hier steht, welche Möglichkeiten/Formate dieses Element ausgeben kann. Ein davon ist audio/x-raw-int.

Der SINK von vorbisenc akteptiert nur  audio/x-raw-float. Wenn pulsesrc nichts anderes können würde, könnten wir die beide auch nicht verbinden. Dafür brauchen wir ein Element welches audio/x-raw-int auf audio/x-raw-float umwandeln kann. Der heißt audioconvert. In unserem Befehl wird so aussehen:

gst-launch-0.10 pulsesrc ! audioconvert ! vorbisenc ! ...

Nun, zum basteln gebe euch ein paar Elemente. Dabei gibt es auch nicht passende ;D

postproc_tmpnoise, pulsesrc, pulsesink, filesink, oggmux, matroskamux, vorbisenc, speexenc

Bin gespannt von euch wieder zu hören.

Achtung! dieser Artikel wurde nicht von einem Muttersprachler geschrieben. Bitte das bei Kritik berücksichtigen. Ich (bed) habe nur die rudimentäre Grammatik und Syntax angepasst.

Die Entwickler von Cheese stehen unter einem Dilemma. Performance und Echtzeitaufnahme. Man sollte genug CPU Leistung haben um sich selbst im Echtzeit aufzunehmen und gleichzeitig in ein passendes Format zu komprimieren. Da ich das selber auf meinem Netbook besonders stark erlebte, wollte ich meine Nase in dieses Problem stecken.

Die erste Frage ist natürlich: welche minimale CPU Leistung ist genug? Muss man den Encoder optimieren dass es noch schneller geht?

Es kam aber raus, so tief in der Codec muss man gar nicht gehen. Wenn der Codec nur das machen würde was sinnvoll ist, würde es schon viel besser gehen. Da fing das Problem an - die WebCams. Man will natürlich immer das bestmögliche Bild haben.

Nun man spricht die WebCam an und sagt: sag mir das beste was du kannst. In meinem Netbook stecke eine von billigsten. Nun die sagt: 1280x1024 und 30fps. Wenn es noch bei keinem klingelt: Eine DVD macht in der Regel 720x576 und 25fps. Natürlich ist der Encoder mit dem hochauflösenden Hochgeschwindigkeitvideo beschäftigt. Auch für meine LeistungsCPU ist es eine harte Aufgabe. Das Blöde in der ganzen Geschichte war, die WebCam lieferte gar keine 30fps, es kam nur 5fps raus. Aber weil Container keine wechselnde framerate handlen konnte, musste man einen Stabilisator ansetzen. Das heißt wenn man keine 30fps bekommt, muss man so lange Duplicate Frames produzieren  bis da 30fps herauskommen. Für uns heißt das 10%  nützliche Leistung, alles andere ist Verschwendung. Die Geschichte ist immer noch nicht zu Ende, da es einige Bugs gibt.

In der Zwischenzeit  prüfte ich noch eine andere Cam und stellte fest, auch meine  Super Logitech verspricht auf den Packung 30fps. In der Praxis macht sie 15fps mit guten Beleuchtung. Wenn man eine 1000W Lampe einsetzt für Beleuchtung, bekommt man schon ~25fps.

In einer Diskussion, welche Auflösung und FPS  man ansetzen sollte, viele Nutzer waren überzeugt das es nicht unter 25fps gehen sollte. Keiner wusste dass sie schon mit 10fps zufrieden waren.

Ich bin zu 99% überzeugt dass, eure Cam auch lügt. Nun schlage ich vor es zu testen und zu prüfen mit wieviel FPS seit ihr zufrieden?

Hier ist der Befehl um es zu testen:

gst-launch-0.10 -v v4l2src ! ffmpegcolorspace ! fpsdisplaysink

Damit wird die WebCam durch v4l2src angesprochen, mit ffmpegcolorspace das Farbsystem für den Ausgang fpsdisplaysink konvertiert. Im Videofenster sollte es aktuelle Framerate zeigen (falls nicht, dann im Terminal). In diesem Beispiel wird es aber die größte Auflösung nutzen und vielleicht weniger Frames produzieren. Für etwas kleineres Auflösung nehmen wir:

gst-launch-0.10 -v v4l2src ! ffmpegcolorspace ! video/x-raw-yuv,width=352,height=288 ! fpsdisplaysink

Bin gespannt welche Ergebnisse von euch kommen

Achtung! dieser Artikel wurde nicht von einem Muttersprachler geschrieben. Bitte das bei Kritik berücksichtigen. Ich (bed) habe nur die rudimentäre Grammatik und Syntax angepasst.

Da ich noch öfter auf gstreamer  zugreifen werde,  glaube ich es hat auch Sinn, darüber ein Artikel zu schreiben.

Gstreamer ist ein Mediaframework. Seine Modularität macht ihn zu etwas besonderem. Jede moderne Distribution nutzt Gstreamer. Es steht hinter Totem, Rythmbox, Cheese, Banshee, Empathy (audio/video chat) und vielen anderen. Wer sich damit beschäftigt, kann auch helfen in genannten Programmen Fehler finden.

In der Regel nutzt man Gstreamer als Library für C, C++, C# oder Python. Man kann es aber auch als Bashscript ansetzen. Dafür gibt es gst-launch (oder in manchen Distros gst-launch-0.10) - ursprünglich diente dieser Befehl als Debuger für Gstreamer interne Sachen. Falls Totem kein Video abspielt, kann man es mit gst-launch prüfen, ob Gstreamer oder Totem daran schuld ist.

Nun, lange Rede kurzer Sinn. Lass uns ein wenig KungFu üben:

gst-launch fakesrc ! fakesink

Gstreamer arbeitet mit Elementen. fakesrc und fakesink sind diese Elementen. Man verbindet die mit Ausrufezeichen "!".

gst-launch audiotestsrc ! pulsesink

Hiermit erzeugen wir ein Audiotestsignal und leiten es durch Pulseaudio auf den Lautsprecher.

gst-launch videotestsrc ! autovideosink

Hiermit erzeugen wir ein Videotestsignal und zeigen es auf dem Schirm.

gst-launch videotestsrc ! autovideosink audiotestsrc ! pulsesink

Und so machen wir beides gleichzeitig.

Um herauszufinden welche Elementen uns zu Verfügung stehen, gibt es den Befehl gst-inspect. Ohne weitere Optionen zeigt es alle Elemente und Formate. In Verbindung mit einem Element wird es Bedienungsanleitung zeigen: gst-inspect pulsesink.

Nun zum Schluss ein Beispiel  für Audioaufnahme:

gst-launch pulsesrc ! vorbisenc ! oggmux ! filesink location=test.ogg

Den zu Entschlüsseln ist jetzt eure Aufgabe.

Achtung! dieser Artikel wurde nicht von einem Muttersprachler geschrieben. Bitte das bei Kritik berücksichtigen. Ich (bed) habe nur die rudimentäre Grammatik und Syntax angepasst.

Welcher Container ist besser OGG oder MKV?

Diese Frage interessierte mich selbst, so stellte ich die Frage den Entwicklern. Eine kurze Antwort ist: OGG ist einfach und gut für mobile oder Embeded Geräte. MKV ist umfangreich – dies wegen auch gut Das ist auch ein Grund warum WebM überhaupt existiert. Man hat die ganze Funktionalität abgeschnitten um es wieder mobil zu machen.

Der feinere Unterschied ist: Die Art und Weise wie ein Videostream synchronisiert wird (Editor:ich hoffe, das ist technisch korrekt?). OGG nutzt FPS (Frames per second) Parameter. MKV und WebM nutzen Timestamps. Das heißt für OGG, wenn man eine Videoquelle mit wechselnden Framerates hat, kommt es zu einer technischen Herausforderung.

Hier sind ein paar der  Antworten die ich bekam:

* Ogg has a lesser semantic burden, so that e.g. embedded
   implementations which necessarily have to be minimal are easier and
   cheaper to build; this of course means that a conforming Ogg
   implementation might not be as feature-rich as a Matroska one
* Ogg is a pure streaming protocol, whereas, IMO, Matroska tries to go a
   bit beyond that; so I'd argue Ogg is a bit better at "doing just one
   thing and doing it well"; I'd say it's "cleaner"
* Ogg goes more with the traditional single-use paradigm than Matroska,
   with its EBML and whatnot; it is still extensible in the IETF sense of
   the word, but more centralized control is effected; IMO that is a good
   thing -- or would you really like such an infrastructure oriented
   protocol to be extended willy-nilly? (think what would happen if
   people did that to IP?
* OTOH, the centralized decision process of Xiph/Ogg is much more open
   than Matroska's
* Because it's a stream protocol, Ogg decidedly isn't fit for
   bit-for-bit file storage; I tend to dislike the idea that an Ogg
   stream is stored as an Ogg file upon transmission
* For one reason or another -- which I'd really like somebody to
   research and document -- there are huge differences in the kind of
   content that is being disseminated using the two formats; I'm
   reasonably sure at least part of the difference has to have something
   to do with the specific needs of the communities using the protocols,
   instead of just adoption discrepancies
* There might just be a bit more coupling between the multiplexing and
   codec design within Ogg than there is with Matroska, which then of
   course means better layer separation/win for the latter; from what is
   seen in the wild Matroska is certainly used to multiplex a far wider
   set of codecs and whatnot than Ogg; but then Xiph/Ogg has its open
   source political aspirations as well, which severely limit what
   is/can be offered
* As a more centralized and "committee-bound" thingy, Matroska was much
   more tighly engineered at its inception than Ogg, and it also seems
   a bit better geared to handle today's
   piece-of-media-over-stream-of-media preferences; I'm thinking this
   could explain much of its current market value

Achtung! dieser Artikel wurde nicht von einem Muttersprachler geschrieben. Bitte das bei Kritik berücksichtigen. Ich (bed) habe nur die rudimentäre Grammatik und Syntax angepasst.

Dieser Artikel soll eine Äbersicht über ogg/theora und webm/vp8. Weiter gehende Informationen  liefert euch Google.

Zuerst eine Begriffsdefiniton. Ogg, webm, avi und weitere sind Tiere von der Art Mediacontainer. Theoretisch kann sich der Inhalt unterscheiden. Jeder von diesen hat eigene Vor- und Nachteile. Aus meiner subjektiven Sicht bevorzuge ich ogg und mkv (matroska). WebM ist nur ein reduzierte (kastrierte) Version von Matroska.

Theora – ist die Weiterentwicklung von vp3, den Codec den die  Firma On2 der Opensource community geschenkt hat. Nach dem Google On2 im Jahre 2009 kaufte, schenkte Google im Mai 2010 einen weiteren Codec: vp8. Seit dem wird an vp8 intensiv gearbeitet, das kann man hier sehen:

https://review.webmproject.org/gitweb?p=libvpx.git;a=summary

vp8 hat eine bessere Kompression im Vergleich zu Theora. Das fordert natürlich auch größere CPU Leistung. Die beiden Codecs sind stehen in Frage für neue HTML5 <video> Tag. Alle Browser die für einen Linuxuser in Frage kommen (Firefox, Opera, Chrome, Chromium), unterstützen vp3 und vp8. Es wird erwartet das mit Android Version 2.3, WebM  auch auf die Smartphones kommt.

Mit Veröffentlichung der vp8 kam Theora teilweise zum Stillstand der Entwicklung. Es ist aber immer noch die beste Option für LoEnd Hardware. Diejenigen, die auch Intel Atom Prozessoren besitzen, sollten auf Theora zugreifen. Die aktuelle stabile Version von Theora ist 1.1 die viel bessere Entwicklungsversion ist 1.2. Die Berichte über Verlauf der Entwicklung kann man auf dieser Seite finden: http://people.xiph.org/~xiphmont/demo/index.html

Also welche Tools unterstützen die beide Codecs? Theoretisch alle moderne Distros sollen damit kein Problem haben. Ubuntu 10.10 ist eine davon.

Mein persönliche Favorit (ich bin nicht gegen ffmpeg oder andere tools) ist gstreamer. Man kann damit beliebige tools konstruieren.

Hier sind paar Beispiele: (Editor: das ! ist wirklich ein Ausrfuezeichen, nicht ein | Pipe, da war ich wohl zu unwissend, deshalb hatte ich alle ersetzt :-(  )

gst-launch filesrc location=in.avi ! decodebin name=demux oggmux name=mux ! filesink location=out.ogg demux. ! theoraenc ! queu ! mux. demux. ! audioconvert ! vorbisenc |queue ! mux.

So konvertieren wir in.avi auf out.ogg.

Und jetzt das selbe nur auf WebM:

gst-launch filesrc location=in.avi ! decodebin name=demux webmmux name=mux ! filesink location=out.webm demux. ! vp8enc ! queu ! mux. demux. ! audioconvert ! vorbisenc ! queue ! mux.

OK, nun vielleicht was komplizierteres, einen dump von DVD auf ogg und zwar die Englische und Deutsche Spur gleichzeitig convertieren:

gst-launch filesrc location=stream.dump ! mpegpsdemux name=demux oggmux name=mux ! filesink location=out.ogg demux.audio_80 ! a52dec mode=2 ! audioconvert ! audioresample ! audio/x-raw-float,rate=44100,channels=2 ! audiorate ! taginject tags="language-code=eng" ! vorbisenc ! queue ! mux. demux.audio_81 ! a52dec mode=2 ! audioconvert |
audioresample ! audio/x-raw-float,rate=44100,channels=2 ! audiorate ! taginject tags="language-code=ger" ! vorbisenc ! queue ! mux. demux.video_e0 ! mpeg2dec ! videocrop top=74 bottom=74 ! ffmpegcolorspace ! videorate ! theoraenc quality=50 ! queue ! mux.

Es gibt auch ganze Reihe von Tools die auf ffmpeg basieren. So z.B. ffmpeg2theora. Einzige Aufgabe dieses Tools ist alles in der Welt auf ogg/theora zu konvertieren. Die aktuellste Version gibt es hier: firefogg.org/nightly/ffmpeg2theora.linux

Dort bekommt man in der Regel die neueste ffmpeg und libtheora Version. Hier ist ein Beispiel:

ffmpeg2theora -v 7 -H 44100 -o out.ogg in.avi

Firefogg ist ein Firefoxaddon mit Frontend für ffmpeg2theora und ffmpeg. Also eine interessante Mischung was auf jedem OS funktionieren sollte. Das ffmpeg wird als Firefoxaddon mit-installiert. Mit wenigen Klicks kann man viele Formate auf ogg/theora oder WebM/vp8 konvertieren.firefogg.org/

Nun damit mache Schluss für diesen Ausflug. Ich hoffe ihr habt Interesse für mehr und wir machen auch ein wenig Scripting oder gstreamer KonFu

PS: es gibt gute Erweiterung für diese Stoff auf folgender Seite:

diveintohtml5.org/video.html