[Kdenlive-devel] piave: AVI DV support

[Jason Wood]

On Sunday 15 June 2003 17:20, Rolf Dubitzky wrote:
> Hi guys,
>
> one thing that was long due is the native AVI DV support. Most wondoze
> programs can write "DV format", where the actual DV frames are inside of an
> AVI container (with or without an extra audio track). dvgrab also writes
> this sort of file. As far as I can tell this has no advantage over raw DV
> files, but at this point I do all my capturing on windoze, since kino
> capturing is constantly crashing on me and with just using dvgrab I cannot
> see what I am actually capturing. So I want to be able to read my AVI DV
> files created on windows. This is done and works very nicely. It is
> committed to the V00-03-devel branch.
>
> If anyone is testing this, I would like to hear if it's working.

Cool, I haven't tested it recently - is the V00-03 branch stable at the 
moment? Does it work with Kdenlive?

> In principle, since I had to write a almost complete AVI parser, it is now
> possible to add native piave codecs for audio/video inside AVI for piave
> (e.g. with libavcoded of ffmpeg).

Cool :-)

> Also I did some further work on enix integration (which would provide it's
> own container parsers for AVI and MPEG etc.), and to tell you the truth, I
> think I was right from the beginning. Editing a video sequence in
> compresses divx files is completely stupid. I think even mpeg might be a
> problem. It's just not possible to do fast searches and move backwards in a
> file. Right now, everything is so slow, it's by _far_ unusable.
> If anything else, it will at least take a lot of work to optimise
> intelligent caching of mpeg-chunks inbetween I frames. There is just no
> single video library for linux which does that. They are all coded with
> fast replay in mind, but not for editing, there it's necessary to cache the
> decoded frames.

I think the important thing here is that piave should be able to read a 
multitude of formats, and export them to dv. Perhaps we should specify an 
attribute with each supported file/codec type. I can't think of a good name 
for it - 'editing suitability' is the kind of idea though - there would be 
three posibilities :

1. Can import file format, can edit file format.
2. Can import file format, can edit file format but it is recommended that it 
be converted to a file format of type 1.
3. Can import file format and export to an editable format, but cannot edit 
directly.

I guess that this would go in the file properties
What do you think?

> If DV wouldn't be limited to PAL or NTSC resolution, I would strongly vote
> for just converting averything you want to edit to DV and then edit it in
> DV. Who cares about disk space these days.

Ok. I think exporting directly to multiple formats is still very useful 
though, and I think being able to import multiple file formats (converting 
them to DV in the process) would also be very useful if handled within piave 
itself. Even if that simply means that piave is calling some external program 
which does the hard work of conversion ;-)

> I think I would rather like to start coding some functionality for
> capturing. Since I would like to play around with Qt anyway, I can also
> implement a little dialog in kdenlive.

Cool, feel free :-) Here is how I was thinking about adding a capture window: 
To make a capture window I would add a base class for monitor functionality, 
which would then be inherited by KMMMonitor and KMMCaptureMonitor (as an 
example name). I believe that the main difference between the capture window 
and a normal monitor will lie in a: the communication between kdenlive and 
piave, and b: the edit bar used to record the clip (which will require a 
'record' buton ;-)). so there should not be too much gui stuff involved.

I envisage the record window as being another monitor tab rather than a 
seperate dialog box.

Just my $0.02 :-)

Cheers,
Jason

-- 
Jason Wood
Homepage : www.uchian.pwp.blueyonder.co.uk