Cinelerra ist ein Videobearbeitungsprogramm fuer Linux. Dabei gab es aber ein paar Herausforderungen. Leider sind die vorkompilierten Debian Pakete fuer Cinelerra entweder nicht mehr erreichbar oder funktionieren nicht richtig. Also selber kompilieren. Folgende Fehlermeldung erschien beim make Programm.

In file included from /usr/include/math.h:94,
                 from common.h:347,
                 from bits.c:28:
/usr/include/bits/mathcalls.h:326: error: conflicting types for 'lrintf'
common.h:313: note: previous definition of 'lrintf' was here

Es lag dann an der veralteten Version von FAAD (Freeware Advanced Audio Coder). Im Cinelerra Source Code ist naemlich noch FAAD2 2.0. Wenn FAAD2 2.7 verwendet wird funktioniert es dann auch. Wenn man den Ordner faad2-2.0 aus cinelerra-4.2-src/quicktime/thirdparty loescht und FAAD2 2.7 verwenden will, muss in der Datei cinelerra-4.2-src/quicktime/Makefile die Variable FAAD_DIR angepasst werden. Sonst findet der Kompiler den Ordner nicht. Bevor man das macht, sollte man allerdings im faad2-2.7 Ordner das Script bootstrap (mit sh bootstrap) und anschliessend noch ./configure ausfuehren. Danach kann im Cinelerra Hauptverzeichniss das make Programm ausgefuehrt werden. Nicht wundern, die Kompilierung dauert sehr lange.

Im Endeffekt hat es dann aber nicht funktioniert. Zu viele andere Compiler-Fehler. Ich hab’ im IRC-Channel #cinelerra auf Freenode nachgefragt, aber da war man auch ratlos. Offensichtlich wollen die Cinelerra Entwickler in den naechsten Tagen ein funktionierendes Source Package fuer Debian erstellen.

13.03.2011, Update: Das erste Problem war eine veraltete FAAD Version, wie oben beschrieben. Ich wollte dann aber doch unbedingt Cinelerra kompilieren. Desswegen schaute ich mir die Kompiler-Fehler nocheinmal genauer an. Die restlichen Fehler tauchten auf, weil das Debian Paket libxv-dev nicht installiert war. Die Entwickler im #cinelerra Channel waren bei der Problembehebung sehr hilfreich. Hier eine Liste mit allen benoetigten Paketen die laut configure-Script benoetigt werden: yasm nasm libc6-dev g++ build-essential libz-dev texinfo libpng-dev libglut-dev libxv-dev libasound2-dev libbz2-dev.

Weblinks

• Cinelerra
• Cinelerra 4.2 Source Code Download
• How to compile CinelerraCV from source code

Ich hab’s mit allen moeglichen Tricks probiert. STDIN, STDOUT und STDERR nach nul (unter Windows nur mit einem L) umleiten, fork(), von einem anderen Script aus mit open eine Pipe oeffnen, mit cmd.exe /C und mit start /B. Und auch all’ diese verschiedenen Moeglichkeiten kombiniert. Aber nichts funktioniert. Ich kann mich an Visual Basic erinnern. Sogar das kann Prozesse komplett im Hintergrund starten. Aber es liegt nicht an Perl, dass die Windows Commandline so beschissen ist. Das zeigt, dass die Linux Shell sehr maechtig ist. Wofuer gibt es dann unter Windows eigentlich cmd.exe, wenn sie nichts kann? Das ist wie der Blinddarm im menschlichen Koerper. Es muss doch eine Moeglichkeit geben, um ganz einfach einen Prozess im Hintergrund rennen zu lassen. Ich will nicht extra Module installieren muessen, nur um dieses Problem zu loesen. Selber schuld, wieso verwend’ ich auch Windows?

Schliesslich blieb mir doch nichts anderes ueber, als ein vorhandenes Perl-Modul fuer diesen Job zu installieren. Jedoch bevor ich ein passendes Modul gefunden hatte, probierte ich folgende Module aus: Daemon::Easy, Working::Daemon, Win32::Console und Proc::Background. Alle haben eines gemeinsam: POSIX::setsid(). ERROR: POSIX::setsid not implemented on this architecture. Will man setsid() unter Windows XP verwenden, wird diese Fehlermeldung angezeigt. Win32::Process war dann schliesslich des Raetels Loesung. Die anderen Module starten zwar auch einen Prozess im Hintergrund, aber sobald cmd.exe beendet wird, werden auch alle anderen Prozesse beendet, die ueber diese Console gestartet worden sind. Win32::Process startet naemlich einen richtigen Hintergrundprozess, vorausgesetzt das cFlag ist DETACHED_PROCESS.

use Win32::Process;
Win32::Process::Create(
	my $proc,
	$^X,
	'perl run.pl',
	1,
	DETACHED_PROCESS,
	'.'
) || die "Win32::Process::Create failed\n";

Benoetigte Perl-Module

• File::Basename
• Win32::Process

Download

• windaemon-1.1.0.zip
• windaemon-1.0.0.zip

iNove vertraegt sich aber nicht mit dem All in One SEO Pack. Beide Extensions haben naemlich im HTML Head-Tag ein Keywords-Meta und ein Description-Meta. Das ist aber nicht gut fuer Google. Desswegen hab ich im File wordpress/wp-content/themes/inove/templates/start.php die Zeilen 39 und 40 geloescht.

39
40

<meta name="keywords" content="<?php echo $keywords; ?>" />
<meta name="description" content="<?php echo $description; ?>" />

Google killt localhost! Der Artikel ueber mein TCP Pipe Script ist wieder komplett aus Google geloescht worden. Er wurde nur kurz, nach der Veroeffentlichung, in Google angezeigt. Kein einziges Wort von dem Artikel hab’ ich bei Google gefunden. Zuerst dachte ich, dass es wegen dem Keywords- und Description-Meta war. Dann hab ich aber festgestellt, dass Google diese Seite als Sicherheitsrisiko ansieht, weil ich localhost verlinkt habe. Ich hab’ die Verlinkung heute in der Frueh heraus genommen und seit Mittag ist mein Artikel wieder bei Google gelistet. Dieser befindet sich auf Platz 18 von 45 Mio. Suchergebnissen, wenn man nach TCP sucht. Das Ganze kann aber genau so auch ein Zufall sein. Weil im Google Cache existiert noch die alte Seite mit localhost Verlinkung und dem Default-Thema.

Wie loest man nun das Problem? Ganz einfach. In der Datei wp-config.php fuegt man folgende Zeile hinzu:

define('COOKIE_DOMAIN', 'DOMAIN.TLD');

Den String DOMAIN.TLD muss man durch die Frontend Domain ersetzen. In meinem Fall also fox21.at:

define('COOKIE_DOMAIN', 'fox21.at');