kdenlive not so "live"

English Multimedia
1

Have browsed forums relentlessly for hours today looking for a fix to this to no avail.
Linux 3.1.10-1.9-desktop x86_64
System: openSUSE 12.1 (x86_64)
KDE: 4.7.2 (4.7.2) “release 5”
kdenlive 0.8.2.1-2.1 via packman@links2linux.de
Sony DCR-TRV320 NTSC camcorder. Old but hella nice.
Camcorder is attached via firewire to the system, hardware monitor reports indicate firewire support is working.
Indeed I have actually transferred video from this same camcorder to this same hardware before when I was running an earlier version of openSuSE. But that was about 2 years ago so I’m kinda relearning the process. I don’t recall if I used kdenlive before actually, but after some reading I thought I’d prefer kdenlive as it seems widely reported a nice stable tool with robust features.

The problem:
If I run kdenlive either from terminal or from gui, the start up process proceeds up to the point of telling me that it doesn’t find a device.

Among other things, testing has included :
Running dvgrab as user in a terminal -it fires right up capturing video.
It was suggested to someone to create a file called 20-udev-firewire.rules in /etc/udev/rules.d with these contents:

# allow video group to read/write /dev/raw1394
SUBSYSTEM=="firewire", GROUP="video",MODE="0660"
KERNEL=="raw1394", GROUP="video", MODE="0660"

so I did that, but no joy.
It was suggested to check the output of

# modprobe raw1394

but that returns

 FATAL: Module raw1394 not found.

YaST reports there is no raw1394 file to install in any repo, however I note that libraw1394 is installed as is libavc1394.
In short, I’ve tried many and varied suggestions. None have helped.

In desperation I uninstalled kdenlive, deleted the file created in /etc/udev and installed Kino.
It recognized the camera immediately.
Doesn’t make any sense to me that dvgrab and Kino see it with no issues.
I like Kino OK but every time you stop the recording the routine crashes. Or at least immediately closes down.
I’m thinking that isn’t normal but in retrospect Kino has ALWAYS done that. Kinda makes it hard to use the features of the software OTHER than the fact that it let’s me get the data from the camcorder and does save the output when it closes down upon me hitting the stop button to end the capture.

Any ideas why I cannot seem to get kdenlive to recognize the camera?

2

It makes sense to me. Different requirements/goals on the part of the developers of this open source free software.

I don’t think it was the intent of the kdenlive developers to support such old cameras.

Rather it makes more sense to me to put the video on your hard drive with dvgrab or Kino and then once the video is on your drive, then drag / drop the video into kdenlive. Ensure you have your project settings in kdelive setup properly BEFORE you try to drag the video in. ie resolution, frame rate … I find that especially useful with larger videos.

You could try to ask the kdenlive developers to add the capability you want, but given they have so many other requests they are working on, I myself would not be too optimistic. You can get kdenlive specific support here: Forums | Kdenlive … its IMHO a very good forum.

3

Why kdenlive searches for dvgrab (“Required for firewire capture”) in the first run if it isn’t to support the cameras that dvgrab supports?

4

Good point.

But in truth, the kdenlive developers rely on the dvgrab developers to test vs various video cameras. The kdenlive developers are more interested in the video editing aspects.

Still, as has been pointed , if dvgrab works, one would expect kdenlive to work.

I’ve seen permission issues with dvgrab, where it did not work well as a regular user, but did work with root permissions. The op did not mention if this was the case (ie dvgrab has permission issues ? ) but instead has us assuming the problem is all kdenlive … It may be. But it may not be.

For the OP did you check out solutions such as this: Grabbing DV from a video camera using DVGRAB/ Kdenlive … you seem to have tried some of this , but possibly not all.

5

Just a further thought on this … (noting I do not have a 1394 device, but that I would like to help) could it be kdenlive needs to pull in some apps that it has not, and hence maybe its dependencies wrt 1394 are possibly not complete ? There is a reasonable possibility that the packager for kdenlive does not have a 1394 device to test this against.

Exactly what rpms with 1394 do you have installed ? ie what is output of:


rpm -qa '*1394*'

For example, I have dvgrab and kdenlive installed, and I have:


libraw1394-**11**-2.0.7-4.1.2.x86_64
libavc1394-**0**-0.5.4-5.1.2.x86_64
libdc1394-**22**-2.1.3-29.1.2.x86_64

but I ask myself, what does the libavc1394-0 mean and what does the libraw-139411 mean ? and what does the libdc1934-22 mean ?

I also note there is a libraw1394 without the ‘11’ and a libavc1394 without the ‘0’. Could it be those different versions are available for a reason related to kdenlive ? The same question for libdc1394. I don’t know … I’m just asking/puzzled.

6

I took a look at the contents of these rpms (out of curiousity to educate myself) :

I took a look at my openSUSE 12.1 and for libavc1394 I noted:

libavc1394-0-0.5.4-5.1.2.x86_64.rpm


/usr/lib64/libavc1394.so.0
/usr/lib64/libavc1394.so.0.3.0
/usr/lib64/librom1394.so.0
/usr/lib64/librom1394.so.0.3.0

libavc1394-0.5.4-5.1.2.x86_64.rpm


/usr/bin/dvcont
/usr/bin/panelctl
/usr/share/doc/packages/libavc1394
/usr/share/doc/packages/libavc1394/AUTHORS
/usr/share/doc/packages/libavc1394/COPYING
/usr/share/doc/packages/libavc1394/README
/usr/share/man/man1/dvcont.1.gz
/usr/share/man/man1/panelctl.1.gz

From the above it appears libavc1394-0-0.5.4-5.1.2.x86_64.rpm provides the kernel modules and libavc1394-0.5.4-5.1.2.x86_64.rpm provides other applications and documentation associated with the kernel modules.

Next libdc1394:
libdc1394-22-2.1.3-29.1.2.x86_64.rpm


/usr/lib64/libdc1394.so.22
/usr/lib64/libdc1394.so.22.1.5

libdc1394-2.1.3-29.1.2.x86_64.rpm


/usr/bin/dc1394_reset_bus
/usr/share/doc/packages/libdc1394
/usr/share/doc/packages/libdc1394/AUTHORS
/usr/share/doc/packages/libdc1394/COPYING
/usr/share/doc/packages/libdc1394/ChangeLog
/usr/share/doc/packages/libdc1394/NEWS
/usr/share/doc/packages/libdc1394/README
/usr/share/man/man1/dc1394_reset_bus.1.gz

From the above it appears libdc1394-22-2.1.3-29.1.2.x86_64.rpm provides the kernel modules and additional applications and documentation are provided by libdc1394-2.1.3-29.1.2.x86_64.rpm

Next libraw1394:
libraw1394-11-2.0.7-4.1.2.x86_64.rpm


/usr/lib64/libraw1394.so.11
/usr/lib64/libraw1394.so.11.0.1

libraw1394-2.0.7-4.1.2.x86_64.rpm


/usr/bin/dumpiso
/usr/bin/sendiso
/usr/bin/testlibraw
/usr/share/doc/packages/libraw1394
/usr/share/doc/packages/libraw1394/AUTHORS
/usr/share/doc/packages/libraw1394/COPYING.LIB
/usr/share/doc/packages/libraw1394/NEWS
/usr/share/doc/packages/libraw1394/README
/usr/share/man/man1/dumpiso.1.gz
/usr/share/man/man1/sendiso.1.gz
/usr/share/man/man1/testlibraw.1.gz
/usr/share/man/man5/isodump.5.gz

From the above it appears libraw1394-11-2.0.7-4.1.2.x86_64.rpm provides the kernel modules and libraw1394-2.0.7-4.1.2.x86_64.rpm provides additional applications and documentation.

The question I would ask, is kdenlive different from kino ? Does one need only the kernel modules, or does one need both the kernel modules and the applications/documentation? I think we may need a packager who has a 1394 device to answer this ? … (or someone a lot better at surfing the answer than I, which given my limited knowledge/capabilities is likely not difficult :frowning: … ).

7

I also note this kdenlive firewire troubleshooting page: Troubleshooting firewire capture | Kdenlive

… I confess while curious, my not having a firewire device makes me not curious enough to figure out where that may apply to your difficulty. Sorry.

8

@OP: The form of udev entry you have for firewire and the raw1394 module is relevant for the old firewire stack only. The current firewire stack is referred to here:

Troubleshooting firewire capture | Kdenlive

The simplest rule to deal with firewire would be

SUBSYSTEM=="firewire", GROUP="video"
9

kernel modules are installed in /lib/modules/. What you see in /usr/lib64/ are plain user space libraries.
When a new version of the library is released it can or can’t be binary compatible with the old one (meaning an application compiled with the old version would be able or not to continue to work with the new version without recompiling). When the new version is incompatible the number after “.so.” is increased to indicate it.
When we package libraries we put that same number in the package name. This way you can install at the same time both versions in case you have some applications that need the old one. But even if the libraries change its name in the new version the binary, /usr/bin/dvcont, would maintain the same name… two different packages trying to install the same, but different, file would not allow to install them at the same time. That’s why the binaries and the rest of the files are in a different package than the libraries.
We do that for all the libraries.

10

Thanks for that explanation !