(42 MB) 00:26:19
2016-03-09 11:00 🛈Vorwarnung: Wenig Inhalt, viel Blabla und QnD-Code
Narf – irgendwo hat mein üblicher Videoeditor „Kdenlive“ seine Metadaten zerstört: Statt den Originalvideos meinte der Editor plötzlich nur noch die herunterskalierten Zwischenvideos verwenden zu können. Versuchen wir mit etwas Scripting die Schnittdatei zu reparieren.
Uhm crap. The last system update just pulled a new beta version of NVIDIAs binary driver. Usually not that much of a deal, I went for testing due to a bug in their stable driver some years ago and never ran into a problem. Well, at least until now. This time the testing-curse found its way into my system and I found myself no longer able to start my video editor kdenlive. Segmentation Fault. I suspected my setup first since I am running a rather unusual multihead configuration but could also with just one monitor I ran into the same problem. Well, looks like I have to dig deeper. Some gdb later at least a clue:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff0b640c5 in XScreenCount (dpy=0x0) at Macros.c:109
109 int XScreenCount(Display *dpy) { return (ScreenCount(dpy)); }
(gdb) bt
#0 0x00007ffff0b640c5 in XScreenCount (dpy=0x0) at Macros.c:109
#1 0x00007fffea7f50da in glXGetClientString () from /usr/lib/libGLX.so.0
#2 0x00007ffff7fed3b3 in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
#3 0x00007ffff7fed5b1 in ?? () from /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
#4 0x00007ffff686fc7b in QSGRenderLoop::instance() () from /usr/lib/libQt5Quick.so.5
#5 0x00007ffff68a19e5 in QQuickWindowPrivate::init(QQuickWindow*, QQuickRenderControl*) () from /usr/lib/libQt5Quick.so.5
#6 0x00007ffff694b68d in QQuickView::QQuickView(QWindow*) () from /usr/lib/libQt5Quick.so.5
#7 0x00000000006bd190 in ?? ()
#8 0x00000000006c3d7b in ?? ()
#9 0x00000000007af3cc in ?? ()
#10 0x000000000046346b in ?? ()
#11 0x00007ffff188e610 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x0000000000463949 in _start ()
So XScreenCount or libGLX is the suspect. In my case GLX is provided by NVIDIAs binary driver (nouveau had limited multihead support last time I checked). Also some QT5-stuff is mentioned in the backtrace.
A bit of search engine voodoo later it turns out NVIDIA already acknowledged the problem. Aaron Plattner writes:
I reproduced the problem and tracked it down to this buggy code in Qt5’s qxcbglxintegration.cpp:
static bool vendorChecked = false; static bool glxPbufferUsable = true; if (!vendorChecked) { vendorChecked = true; const char *glxvendor = glXGetClientString(glXGetCurrentDisplay(), GLX_VENDOR); if (glxvendor && !strcmp(glxvendor, "ATI")) glxPbufferUsable = false; }When this code is called during sddm-greeter startup, there’s no current GLX context, so this gets called with a NULL argument.
While here SDDM is not the problem I think kdenlive, which uses similar libraries, runs into the same problem. He also pushed a corresponding patch to NVIDIAs GIT-repository. Sadly the current HEAD is not 100% ABI compatible with the official driver release. Also I really didn’t want to get into my distributions xorg-packaging-foo. Ultimately I reverted to the current NVIDIA stable version 358.16 to get back into business. So – lesson confirmed: Beta releases can fix problems or cause problems. But who doesn’t like a bit of stability-gambling, right?
(30 MB) 00:15:52
2014-10-17 23:05 🛈Mit AVidemux und OpenShot haben wir schon den einfachen Videoschnitt hinter uns – Zeit in die komplexeren Programme einzutauchen: Cinelerra und Kdenlive sind mächtige Programme und müssen sich zumeist nicht hinter kommerziellen Lösungen verstecken.
Egal wie ruhig man ist: Auf großen Zoomstufen oder beim Bewegen verwackelt fast jedes Video. Professionelle Aufnahmegeräte bieten für diesen Zweck meist eine Stabilisierung in Kamera oder Objektiv, dies ist jedoch aufwändig und kostet entsprechend viel Geld. Besitzer von Consumergeräten müssen aber nicht ganz auf eine solche Stabilisierung verzichten: Viele Videoeditoren bieten entsprechende Bildfilter, welche (auf Kosten der Videoqualität) softwareseitig die Stabilisierung übernehmen. Als kostenlose Lösung ist vielen die entsprechende Funktion der Videoplatform YouTube bekannt, jedoch lässt sich diese nur auf komplette Videos anwenden und ist nicht konfigurierbar, zudem möchte man nicht jedes Video auf der zu Google gehörenden Platform bereitstellen. Leider sieht es unter Linux dünn aus – zwar kann man über wine die Lösung Virtualdub/Deshaker nutzen und der Editor KDEnlive bietet passende Filter im Menü, beide Lösungen lassen sich jedoch nur schwer automatisieren und leidet unter nervigen kleinen Bugs.
Bild: https://www.adlerweb.info/blog/wp-content/uploads/2013/05/kdenlivestab.png
Um nun bei mir das ganze zu erschlagen habe ich ein Script geschrieben, welches alles nötige übernimmt. Die eigentliche Stabilisierung steckt in der Software transcode, da diese jedoch mit vielen Codecs Probleme hat muss das Video entsprechend vorbereitet werden. Durch den Zwischenschritt als MPEG2 ist temporär ein vielfaches des ursprünglichen Speicherplatzes nötig, der sollte beim Umgang mit Videos ja ohnehin reichlich vorhanden sein. Das Ausgabeformat ist derzeit auf 8MBit/s x264 mit 128k MP3 eingestellt, der Stabilisierungsfilter läuft mit Standardwerten.
ffmpeg -i $1 -vcodec mpeg2video -b:v 10000k $1.mpg
ffmpeg -i $1 -acodec libmp3lame -b:a 128k $1.mp3
transcode -J stabilize -i $1.mpg -y null,null -o dummy
transcode -J transform -i $1.mpg -y xvid,pcm -w 10000k -o $1.stab.temp.mp4
ffmpeg -i $1.stab.temp.mp4 -i $1.mp3 -vcodec libx264 -acodec copy -b:v 8000k -map 0:0 -map 1:0 $1.stab.avi
rm $1.stab.temp.mp* $1.mp3 $1.mpg $1.*.trf
Voraussetzungen sind ffmpeg und transcode. Debian/Ubuntu liefern zum Teil statt ffmpeg dessen Fork avconf, in diesem Fall einfach im Script den Befehl anpassen.
