I don't know maybe it is MLT problem but video editing in 0.76 for me is awfully slow compares to 0.75.
My camcorder is Panasonic HDC HD-9, My PC is AMD Phenom x4 9650 RAM-4G + Kubuntu amd64 9.04
In 0.75 there was several bugs with transition effects between cropped parts of one movie clip. But I can easy navigate through my video using project monitor: play pause, using mouse scroll to shift by frames, etc.
Now in 0.76 there are no problem in transition, but every action on movie clip became very slow. It takes about 30 seconds to do something: playing, move clip, apply transition, crop movie clip, etc.
It is impossible to work with kdenlive in this case. I'm confused :(
- Login or register to post comments
- 1774 reads
- Flag as offensive
- PDF version
Strange. I'm on a underpowered laptop, and 0.76 is the first version that I can navigate correctly. Vast improvement on my system
I'm on Ububtu 9.10, 32bit.
I was waiting for someone to post about this. :-)
Panasonic HDC HD-9 is an AVCHD camera. In the latest release of MLT, for H.264 in Transport Stream (AVCHD's format), we fixed seeking to be accurate and artifact-free, which were problems prior. Unfortunately, the cost was a big hit in performance. Until there are performance remedies, you must learn to seek very carefully. Or, transcode to DNxHD. There is a chance VDPAU and/or VAAPI will help sometime in the not too distant future.
It's two year and more that I use and enjoy kdenlive.
I have a OpenSUSE 11.0 Linux box with kde 3.5 .
My camera is a Panasonic TZ7 which captures video in AVCHD 720p format.
I could edit the clips shot with the camera without any problem with the 0.7.4 and 0.7.5 releases of kdenlive.
Now, with the 0.7.6 release I can add one clip (.MTS file) in the project and view it in the clip monitor, but when it is dragged in the time line it can't be played in the project monitor and the program freezes.So Kdenlive 0.7.6 is not usable for me.
ffplay and melt can play the clips all right.
Is this problem due to mlt 0.4.6?
How could it be fixed?
Thanks for helping me.
gpasquar,
Can you provide a short sample clip? Maybe attach it to a bug report in our bug tracker or share it on rapidshare.com.
From the sound of it, since it plays in melt and the clip monitor it seems like it is working fine fundamentally and maybe there is something wrong in the process of adding it to the timeline. I want to see if I can reproduce it with one of your clips.
Dan, thank you for your reply.
I sent you a short clip (100 Mb) of mine with rapidshare (email: dan@dennedy.org) .
yes you are right i encountered the same problem with it
gpasquar,
I downloaded your sample and reproduced your problem. Until I debug it, here is a workaround. In Kdenlive Settings, create a new Transcode profile:
DNxHD 1280x720 25p 110 Mb/s = -s 1280x720 -r pal -b 110000k -threads 2 -vcodec dnxhd -acodec copy %1.mov
If you do not want to create new, big files, here is a workaround to revert it to the old behaviour - this works for any AVCHD.
$ melt 00053.mts new_seek=0 -consumer xml:00053.mlt
Now, load the .mlt into Kdenlive as a clip. People with 30p/60i should use:
$ melt -profile atsc_1080i_60 00053.mts new_seek=0 -consumer xml:00053.mlt
The .mlt proxy might cause you to have artifacts after trimming the clip, but the DNxHD will not.
Dan,
thank you very much for your fast and useful reply.
I tried the second workaround you have proposed: it works very well! So I can use kdenlive 0.7.6 now with a very low effort.
For other users who encountered this problem, this is a little script to extend your suggestion and create all .mlt files from .mts files saved in one folder:
#
ls * | while read f
do
melt $f new_seek=0 -consumer xml:${f%.*}'.mlt'
done
#
I had the same bug with my Panasonic HDC SD-9 and the workaround with the .mlt seemed to work fine. However there are indeed some artifacts, actually it is impossible to use transitions with two clips that were part of a single source file. :/
I guess I have to use the first trick, I mean, transcoding the file. I don't want to rescale my clips as I want to keep them full HD, so I suppose I have to use the existing conversion filters, for instance 1920x1080 25p ? But the point is, will I not lose some quality in this process ? The files produced are very big, thus is a bitrate such as 120M/s sufficient or should I prefer 185M/s ?
Last, do you plan to solve this bug in a future version ?
Thank you very much for your time !
>>There is a chance VDPAU and/or VAAPI will help sometime in the not too distant future.
I hope it will help. As I understand my video card Nvidia 8600 GT will have VDPAU abilities.