Hi all,

first of all the version 0.7.1 rocks !! Great Work, Thank you guys.

Just one question at the moment, on my slow box (AMD Athlon XP 2600+ GeForce FX5500) the project preview run very jerky, in a staccato way. I can rember the version 0.5 has somewhere an option to configure the quality of the video preview. This made it possible to have an acceptable preview for working.

But now in 0.7.1 I can't find this option. Is it gone?

 

CU

Tom

The preview quality and performance is determined by your project setting and format/codecs of clips. Please provide that information. Also, please try different types of clips and see if you notice anything.

Thanx for your replay.

I tried several project settings, but with no sucess. In fact the problem with the jerking preview seems

to me independent from the project settings. Maybe it is only the problem that the audio track is jerky, the

video seems working ok. Is there a configuration option under opensuse 11.1 to give the audio process more priority?

BTW: The same video is running perfectly with kaffeine and mplayer.

CU

Tom

Are you running a sound server like Pulseaudio?

If so, try forcing kdenlive to use OSS instead therefore bypassing the sound server.

 

- Si

Hm, yes I think with KDE 4.1 under opensuse 11.1 pulseaudio is running.

So I  tried all available options also OSS and OSS with DMA Access, but

without any effect.

I even switched off the video output to have just the audio track. So the sound

is distorted, but other applications on my box which produce audio are working

well.

Any Ideas?

 

CU Tom

Make sure that pulseaudio doesn't have any sort of OSS interception enabled.

How can I do that?

Thanx

Tom

I recognized that the cpu load on my box goes to 100% when I play the clip in kdenlive. This will raise this jerky effect. When i am playing the same clip in kaffeine the is max. 30%.

So I think this issue is solved.

 

CU

Tom

yest it's true seems to get very jerky and after while even stops (using HD 1280x720)

hope gets better and more fluid as Premiere manages.. (cheers..:)

I too am experiencing the choppy/jerky preview windows and am running on an AMD Sempron 2800+ with Nvidia MX4000. I upgraded the RAM from 512MB to 2GB(maximum for this motherboard) hoping that this would solve the problem.

I had a slight improvement but it's still too choppy and preventing me from using Kdenlive.

I'm trying to decide whether it's worth upgrading the CPU from the 2800+ Sempron to a 3400+ or 3700+ Sempron. (Maximum for this motherboard), However I'm wondering whether this will make any difference.

Does anyone use Kdenlive on a 2800+, 3400+ or 3700+ Sempron system? If so please post your experiences. I'd appreciate the feedback in order to decide whether it's worth upgrading.

Thanks

Rob

bump

Here is how to track down where the issue might be. You basically need to test playback in a bottom-up fashion. Choose a single clip to test with. Put it on the timeline at the beginning and save the project. Make a note of the project setting you are using. Then, run the following tests while monitor cpu usage:

1.) ffplay clip
2.) inigo clip -consumer sdl rescale=none progressive=0
3.) inigo -profile atsc_1080i_50 clip
4.) inigo -profile atsc_1080i_50 test.kdenlive
5.) play in kdenlive

Replace 'inigo' in the above with 'melt' if you are using MLT v0.4.0+.
Replace 'atsc_1080i_50' with whatever best matches your kdenlive project setting. The set of available profiles are in /usr/share/mlt/profiles.

Test #2 in the above suppresses any software scaling and deinterlacing. MLT automatically scales in software by default because the images are typically needed for filtering, encoding, or mixing with clips of different resolution. MLT profiles also indicate if the output is progressive or not, and if not, interlaced clips are automatically deinterlaced. So, test #3 allows the MLT automagic stuff to happen. Test #4 mixes in the complexity of processing multiple tracks and which clip plays when.

There are also other factors that makes MLT slower than players and ffplay. For one, it upconverts the chroma channels from planar YUV 4:2:0 to packed YUV 4:2:2. This is partly historical, but also makes for a little better quality and sometimes easier to adapt RGB-based image processing routines to YUV. Secondly, many players do not automatically deinterlace interlaced video; often just DVDs if there is an automatic option. Third, players do not have to do software scaling for the reasons given above. Another factor is that MLT has more work to do than just a player. It has to provide a library that allows for complex expression of a video editing project and the manipulation of that project going well beyond simple playlist management. Finally, we simply have not had the manpower or time yet to give full attention to optimization or playback quality for the SDL output - the lead developer left a while ago, and I chose to evolve and maintain Kino for a good while until the beginning of this year.