vpinon wrote:And why running Linux on Linux through a VM? (s)chroot/LXC/Docker are so much lighter (as long as your host kernel is not too old)

Cause this ain´t a Linux host

@Steve: Will provide crash logs later. Starting this week I have to work again as my vacation is over.

Steve Guilford wrote:Crashes are my specialty. Run the program from the command line and let us know what it says...

Alright, log is here: http://pastebin.com/raw.php?i=Bedi6f49
I tried to add http://www.engr.colostate.edu/me/facil/dynamics/files/bird.avi to a newly opened, empty project.

larsend wrote:

Steve Guilford wrote:Crashes are my specialty. Run the program from the command line and let us know what it says...

Alright, log is here: http://pastebin.com/raw.php?i=Bedi6f49
I tried to add http://www.engr.colostate.edu/me/facil/dynamics/files/bird.avi to a newly opened, empty project.

Your clip loads up fine for me. 9 seconds of a rotary gear driving bird wings I guess.

I really think you are being victimized by having to run within a VM. All of those thread ownership errors are certainly unique to your environment. I have a fully debuggable version of Kdenlive (0.9.10) and do not get any complaints when loading up your clip.

Sorry, but that VM would be the first thing (complexity) that I'd eliminate.

In the meantime, I installed Kubuntu in another VM and using the distribution´s packages, I now have Kdenlive 0.9.6 with vid.stab out-of-the-box.
Therefore, I don´t think the VM is the problem. But I will also try the build script.

larsend wrote:In the meantime, I installed Kubuntu in another VM and using the distribution´s packages, I now have Kdenlive 0.9.6 with vid.stab out-of-the-box.
Therefore, I don´t think the VM is the problem. But I will also try the build script.

OK...maybe not VM technology per-say but rather, that VM configuration. Kdenlive is a pretty finicky program. Lot's of dependencies and path requirements that are easily fubar'd.

I know the new vid.stab compiles, integrates and works w/ Kdenlive - I did the integration. So, if you are going to try the build script then my recommendation is to do so in a clean, fresh VM installation - one that has not been used to run Kdenlive previously.

Steve Guilford wrote:So, if you are going to try the build script then my recommendation is to do so in a clean, fresh VM installation - one that has not been used to run Kdenlive previously.

Restored my snapshot where only the OS has been installed, but no Kdenlive version whatsoever.
Used the build script to compile Kdenlive in my Kubuntu VM.

Same crash when adding a video clip:
kdenlive: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

On further tries, after adding the video I got the dialog "Your clip doesn´t match current project´s profile" and Kdenlive froze. Some seconds later, a dialog 'Application "kdenlive" is not responding' appeared and I could terminate it.

So, the build script doesn´t work for me inside VirtualBox, but I will try to find out what difference there might be between my Debian and Kubuntu VM regarding the other installation methods, hoping to get the filter running in Debian, too.

I already did a search but couldn´t find an answer: Could anyone please tell me how Kdenlive finds it´s filters? Are they supposed to be in a specific directory?

Yuk...sorry.

So, working from the assumption that the VM is not an issue, let's continue on. Given your success w/ 0.9.6 on that other VM I think we can safely assume that for now and focus elsewhere.

A quick search of

Code: Select all

xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.

Yields this interesting hit:

https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1301058

Do you have LibAV installed? Some do and others do not know that LibAV is a fork off of FFMpeg. This may cause problems. For that matter is FFMpeg installed as a distro-package. The build script is supposed to produce an isolated copy of Kdenlive but let's not rely entirely upon that and eliminate one other 'variable' - other installed packages that may interfere. So, if either of the aforementioned two are installed, remove them, rebuild and try again.

As far as the Vidstab installation and how Kdenlive finds it, I downloaded this version:

georgmartius-vid.stab-release-0.98b-0-g3b35b4d.tar.gz

Unpacked, built and installed from /usr/local/src. Probably ran ldconfig as well. This results in:

/usr/local/include/vid.stab/libvidstab.h
/usr/local/lib/libvidstab.so
/usr/local/lib/libvidstab.so.0.9

From there, I ran the kdenlive build script. At startup, Kdenlive asks MLT if it can build a filter by the given name for the video stabilizer. If so, Kdenlive includes the video stabilizer as a viable option in the Clip Jobs menu. I didn't dig through the code but it's safe to assume that MLT picks up the fact that libvidstab.so is in my local/lib directory (remember, ldconfig...) and successfully builds the requested filter.

Other filters are detected using a similar fashion. Here's the code if you're dying to know....

Code: Select all

void MainWindow::loadClipActions()
{
    QMenu* actionMenu= static_cast<QMenu*>(factory()->container("clip_actions", this));
    if (actionMenu){
        actionMenu->clear();
        Mlt::Profile profile;
        Mlt::Filter *filter = Mlt::Factory::filter(profile,(char*)"vidstab");
        if (filter) {
            if (!filter->is_valid()) {
                delete filter;
            }
            else {
                delete filter;
                QAction *action=actionMenu->addAction(i18n("Stabilize (vid.stab)"));
                action->setData("vidstab");
                connect(action,SIGNAL(triggered()), this, SLOT(slotStartClipAction()));
            }
        }
        filter = Mlt::Factory::filter(profile,(char*)"motion_est");
        if (filter) {
            if (!filter->is_valid()) {
                delete filter;
            }
            else {
                delete filter;
                QAction *action=actionMenu->addAction(i18n("Automatic scene split"));
                action->setData("motion_est");
                connect(action,SIGNAL(triggered()), this, SLOT(slotStartClipAction()));
            }
        }
        if (KdenliveSettings::producerslist().contains("framebuffer")) {
            QAction *action=actionMenu->addAction(i18n("Reverse clip"));
            action->setData("framebuffer");
            connect(action,SIGNAL(triggered()), this, SLOT(slotStartClipAction()));
        }
    }

}

I am back at my snapshot with a Debian Jessie installation where the Kdenlive package has been installed and where I compiled libvidstab.

Steve Guilford wrote:Do you have LibAV installed? Some do and others do not know that LibAV is a fork off of FFMpeg. This may cause problems. For that matter is FFMpeg installed as a distro-package.

Code: Select all

debian:~# dpkg -l *ffmpeg* *libav* | grep ii
ii  libav-tools               6:11-1       i386         Multimedia player, encoder and transcoder
ii  libavahi-client3:i386     0.6.31-2     i386         Avahi client library
ii  libavahi-common-data:i386 0.6.31-2     i386         Avahi common data files
ii  libavahi-common3:i386     0.6.31-2     i386         Avahi common library
ii  libavahi-core7:i386       0.6.31-2     i386         Avahi's embeddable mDNS/DNS-SD library
ii  libavahi-glib1:i386       0.6.31-2     i386         Avahi GLib integration library
ii  libavc1394-0:i386         0.5.4-2      i386         control IEEE 1394 audio/video devices
ii  libavcodec53:i386         6:0.8.6-1    i386         Libav codec library
ii  libavcodec54:i386         6:9.8-2+b2   i386         Libav codec library
ii  libavcodec55:i386         6:10.1-1     i386         Libav codec library
ii  libavcodec56:i386         6:11~beta1-2 i386         Libav codec library
ii  libavdevice55:i386        6:11-1       i386         Libav device handling library
ii  libavfilter5:i386         6:11-1       i386         Libav video filtering library
ii  libavformat53:i386        6:0.8.7-1    i386         Libav file format library
ii  libavformat54:i386        6:9.8-2+b2   i386         Libav file format library
ii  libavformat55:i386        6:10.1-1     i386         Libav file format library
ii  libavformat56:i386        6:11-1       i386         Libav file format library
ii  libavresample2:i386       6:11~beta1-2 i386         Libav audio resampling library
ii  libavutil51:i386          6:0.8.7-1    i386         Libav utility library
ii  libavutil52:i386          6:9.8-2+b2   i386         Libav utility library
ii  libavutil53:i386          6:10.1-1     i386         Libav utility library
ii  libavutil54:i386          6:11~beta1-2 i386         Libav utility library


When I remove libav-tools, Kdenlive is removed automatically. As I only noticed this after all that comes down below, I will try the build script tomorrow. It´s too late now.

Steve Guilford wrote:georgmartius-vid.stab-release-0.98b-0-g3b35b4d.tar.gz

I cloned the git repository and after compiling/installing got this:

Code: Select all

/usr/local/include/vid.stab/libvidstab.h
/usr/local/lib/libvidstab.so -> libvidstab.so.1.0
/usr/local/lib/libvidstab.so.1.0

Other information that might be useful:

Code: Select all

# dpkg -l *mlt* | grep ii
ii  libmlt++3      0.9.2-2      i386         MLT multimedia framework C++ wrapper (runtime)
ii  libmlt-data    0.9.2-2      all          multimedia framework (data)
ii  libmlt6        0.9.2-2      i386         multimedia framework (runtime)
ii  python-mlt     0.9.0-1+b1   i386         multimedia framework (python bindings)

Code: Select all

ldconfig -p | grep stab
        libvidstab.so.1.0 (libc6) => /usr/local/lib/libvidstab.so.1.0
        libvidstab.so (libc6) => /usr/local/lib/libvidstab.so

Shouldn´t MLT already contain vidstab?
There is code here: https://github.com/mltframework/mlt/tre ... s/vid.stab
and this file is in package libmlt6: /usr/lib/i386-linux-gnu/mlt/libmltvideostab.so
What is the difference between this and the compiled vid.stab from georgmartius?

in 0.9.10 the vstab was moved out into a separate dependency.
this thread suggests that the build script should build it for you.

Ok, tried again with Debian Jessie, 64-bit. Fresh VM snapshot without anything Kdenlive related explicitly installed.

- Installed via buildscript: Kdenlive crashes on adding a clip
- Separately compiled libvidstab from git repo. Had to run ldconfig to get the libs listed in "ldconfig -p": still crashes

Searched for the error message again. There is a bug report concerning gnuplot: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751441

Code: Select all

We stop to provide wxt-terminal because wxwidgets 3.0 is not compatible
with gnuplot [1], [2]. wxt-terminal will be enabled again if the bug
will be fixed.

  [1] https://sourceforge.net/p/gnuplot/bugs/1401
  [2] https://bugs.debian.org/750045

Might this be the reason? See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750045

Code: Select all

So there's likely some code in gnuplot which makes a wx API call which
isn't valid, and wx 2.8 just ignored this, but 3.0 pops up this
assertion dialog.

Same problem with Kdenlive? Now, I don´t know if Kdenlive even uses wxwidgets...

Hello
MLT still includes the obsolete "videostab"/"vidstab" modules for backward compatibility. Kdenlive 0.9.10 removed menu entries for old stabilizer to make users use the recommended "vid.stab" library (note the dot in the name!).
We are in the transition where distro packagers get aligned with latest technology (I mailed Debian/Ubuntu maintainer about that few days back).
In the meantime you should either stick to older version (on Debian/Ubuntu "pinning" is your friend), or use daily builds (PPA for Ubuntu, meltytech archives for anything else). If you really want to build by yourself (?), really do use the MLT build script or you will certainly miss components. If build script misses build-dependancies, on Debian "pinning" is your friend again (with "unstable" archive).
Last resort : stabilizers must be also available from command line using melt, or maybe also ffmpeg/libav/transcode, but I never used it like this.

Hi,
thanks for the insight.

vpinon wrote:If you really want to build by yourself (?), really do use the MLT build script or you will certainly miss components. If build script misses build-dependancies, on Debian "pinning" is your friend again (with "unstable" archive).

Yes, I have really used the build script. I don´t know if that missed dependencies cause it compiled successfully, and if it is responsible for the crash I am experiencing.
What exactly should I pin? Which archive of what?

Sorry I was repling to your previous post, you sent your update while I was writing.
If you successfully ran the build script, there's no more package to pull from unstable.
Kdenlive doesn't use wxWidget, but it does rely on LibAV, which is source of quite many problems
I don't really know how to help more if you are stuck with the graphic stack of the VM & libAV.
Either use old distro version with old Kdenlive package, or use a distro not using libAV (Debian, Ubuntu & derivatives) but FFmpeg (eg OpenSuse, Arch...)?

Fortunately, Kdenlive does not use wxWidgets. wxWidgets is horrid - in my opinion. Where you're getting that error from baffles me. Did you provide the full text in an earlier post?

Please remove both the Kdenlive and the LibAV packages. When they forked LibAV from FFMpeg, they took the dishonorable route of NOT changing the library names. This causes all sorts of problems. Ostensibly, they wanted to offer LibAV as a drop-in replacement for FFMpeg. I think it's insane however to expect a forked project to maintain strict compliance. The least they could have done was offer a 'substitution' library that can be installed which maps FFMpeg libraries over to the LibAV libraries in order to enable unique names to the LibAV stack. But...I digress.

Kdenlive does not directly depend on LibAV or FFMpeg. Rather, it uses services exposed by MLT. I checked the link-line and there's no references to anything within the LibAV or FFMpeg stacks.

Check and see what 'locate libavcodec.so' has to say. You should not have any 'distro' provided libav components.

Run the build script again on a fresh subdirectory (no previous Kdenlive installations). Have a look at 'locate...' again. You should have a bunch of hits within the Kdenlive build directories.

We want to be absolutely sure that Kdenlive is using the libraries we expect.

Thanks for bearing with me...I love a mystery

Kdenlive doen't depend on ffmpeg/libav at build time, but it uses these utilities for transcode actions, so distro packagers attach a dependance for full functionality.

(side remark: libav fork is a long and sad story, but it had some positive impacts too, it seems difficult to have a clear opinion... one of libav goal, aside governance, was to change the API to deeply clean it, and ffmpeg is maintaining the compatibility on its side!)