On Sat, Oct 29, 2011 at 7:27 AM, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
Hi list,

I have a problem with Kdenlive, both on a Gentoo and Ubuntu computer. It
was built from head using the scripts from
http://www.mltframework.org/twiki/bin/view/MLT/BuildScripts because with
both the distribution version of Ubuntu 11.10 and Gentoo, I experienced
severe A/V delays when editing/transcoding.

Now earlier when I clicked in the "middle" of a video, it took on my
Q9550 PC about half a seocond to update the picture (ffmpeg 0.7.6, melt
0.5.10, kdenlive 0.7.8).

It is well known that seeking on AVCHD is horribly slow. Is this version combination something you tested today or are you basing this on on a memory? I have a lot of trouble believing your above claim is possible. 

Does the machine have NVIDIA GPU with NVIDIA binary X driver? Possibly that build of ffmpeg and mlt supports VDPAU. Run 'melt -debug avchd.mts 2>&1 | grep vpdau'
If it the console out contains many messages with 'vdpau' in them, it is using VDPAU. 

VDPAU does provide some speed benefit on systems with weak CPU, but I have not seen it improve seeking much, and it causes much more instability, which is why it is now disabled by default. Still, it would be interesting to see if this combo is the reason.  
 
Now with the HEAD version (built 2011-10-29,
ffmpeg git-2011-10-29-6faf0a2, melt 0.7.5, kdenlive 0.8.1 rev 5997), it
takes about 4-5 seconds for the picture to update, once I clicked on the
timeline.

This is what is expected.
 
Videos are AVCHD ("MTS" extension) directly from the camcorder, example
at https://spornkuller.de/00022.mts

If there's anything I can do to debug this problem, please let me know!

People are re-wrapping, transcoding, or using proxy clips for anything but very light editing with AVCHD.

--
+-DRD-+