[Kdenlive-devel] kdenlive-HEAD very slow on timeline click in AVCHD videos

[Johannes Bauer]

Hi Dan,

>> 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.

You mean the half second is incredible? I tried this out today and it I
am 100% certain. Actually I just removed the Gentoo-version of kdenlive
(my locally built GIT version conflicts with some audio plugins
apparently), but I'll happily reemerge the version and reproduce this.

However, even if I report this, I do not know how to increase my
credibility. Are there any performance debug outputs that I could enable
to make you believe me?

Also, I noticed something: When I had a kdenlive-file saved with the
Gentoo ("fast") version and loaded it with the GIT-version, seeking was
also fast there.

> Does the machine have NVIDIA GPU with NVIDIA binary X driver?

Yup!

> 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.

The version I built from GIT returns nothing, therefore no vdpau. After
reemerging the Gentoo version, I'll try with that again to confirm this.
Is it possible to enable VDPAU with the repositories from HEAD (mlt and
ffmpeg) or are these separate patches that Gentoo would maybe include?

Indeed when I query ffmpeg for its Gentoo build flags, the nvidia card
comes up (I reformatted the output for better readability), but the
vdpau flag is disabled:

Enabled:
3dnow 3dnowext X aac alsa bzip2 encode hardcoded-tables mmx mmxext mp3
sdl ssse3 theora threads truetype v4l v4l2 vorbis x264 xvid zlib

VIDEO_CARDS="nvidia"

Disabled:
(-altivec) -amr -avx -bindist (-celt) -cpudetection -custom-cflags
-debug -dirac -doc -faac -frei0r -gsm -ieee1394 -jack -jpeg2k -network
-oss -pic -qt-faststart -rtmp -schroedinger -speex -static-libs -test
-vaapi -vdpau -vpx

Similar with melt (althogh that has no explicit nvidia flag), but vdpau
would have been disabled there, too :-(

[ebuild  N     ] media-libs/mlt-0.5.10  USE="dv ffmpeg gtk kde melt
python qt4 sdl sse sse2 vorbis xml -compressed-lumas -debug -frei0r
-jack -libsamplerate -lua (-mmx) -quicktime -ruby -vdpau -xine" 0 kB

Any other reason that would explain that fast seeking?

> 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.

:-(

The Gentoo version causes some A/V asynchronizity, which is why I use
the more recent mlt/kdenlive versions. However, the fast seeking speed
was very nice.

>> 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.

I see - was hoping so much to avoid this. Searching the net I found some
instructions on how to transcode to DNxHD or mjpeg. When not trying to
lose quality upon the extra transcode, filesizes just go supernova (185
MBit for DNxHD for 1080 video). Are there any options which do not suck
that bad?

Best regards,
Joe