[Kdenlive-devel] Kdenlive 0.7 SVN: my questions

[Dan Dennedy]

> I have built ffmpeg, mlt. mlt++ and kdenlive packages for Kubuntu 8.10 amd64
> and made some test. The GUI part looks very good and almost stable, it
> crashes only two times for a day, not bad.
>
> Where is a scene detection (especially for DV sources) when I load a clip?

Non-existent. You can use autosplit with dvgrab during capture to
help. I can add some metadata within MLT that would help an app scan a
video clip and look for edit points. Then, the app could automatically
add multiple playlist entries.

> Where is a double pass DVD encoding profile. The default one pass PAL-DVD
> profile with 5000k of video bitrate produces ugly output.

It is possible on the command line using inigo:
$ inigo -profile dv_pal some.kdenlive -consumer avformat:out.vob pass=1 ...

paste your options from the render dialog's info panel to the end of
that and tweak it from there.

> Try to add 16x9 DV clip on timeline, make some editions, then export to DV
> file. What is happen with aspect ration of result DV?

I don't know; I can't see your screen. What is the project profile and
render setting?

> If I have DV clip, I make some editions, just cut and mix without any
> transition, why it recodes the material, it can simple pass trough the DV
> frames in right sequence to output DV. Isn't it?

This is not a DV only editor. That is trivial for a DV only editor. It
is still on my ToDo list for MLT because I have been focusing mainly
on stabilization and fixing obnoxious design flaws. This does not
qualify as an obnoxious design flaw; it is an optimization. Some of my
other, commercial projects for MLT do not require this and would not
take advantage of it, which is another factor, because it affects
priorities and time is limited.

> MLT developers may introduce dv2sub functionality to its library as
> consumer, to allow users get the DV timecode.

This will be a part of the work to facilitate autosplit. Of course, it
will not use dv2sub. Rather, it will be a filter using libdv that
simply annotates the MLT frames with metadata as opposed to doing any
image or audio processing.

> Unfortunately (for Kdenlive), Kino is much better.

Of course, you know I was Kino lead developer, but please keep in mind
that MLT was not designed specifically for replacing Kino. Kino is
DV-centric so it was easy to do some sophisticated things. It is more
difficult to do the same things in a generic way or introduce
format-specific optimizations in a generic framework. Your point
simply illustrates that the software still has much more to mature and
that there is no very comprehensive solution yet. Well, at least I
understand the issues you raise well enough to work on them for MLT.
Meanwhile, I expect many HDV users (and potentially AVCHD) will
disagree with you. :-)

--
+-DRD-+



-- 
+-DRD-+