This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Not actually a bug, but very bad feature in 0.76

Tags: None
(comma "," separated)
zx_master_drupal
Registered Member
Posts
8
Karma
0
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 :(
Xamiga
Registered Member
Posts
38
Karma
0
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.
ddennedy
Registered Member
Posts
1315
Karma
1
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.


zx_master_drupal
Registered Member
Posts
8
Karma
0
>>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.
ddennedy
Registered Member
Posts
1315
Karma
1
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.


ddennedy
Registered Member
Posts
1315
Karma
1
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.


Flavien
Registered Member
Posts
3
Karma
0
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 !


Bookmarks



Who is online

Registered users: Bing [Bot], claydoh, Google [Bot], rblackwell, Yahoo [Bot]