[Kdenlive-devel] piave: AVI DV support

[Rolf Dubitzky]

On Sunday 15 June 2003 18:45, Jason Wood wrote:
> 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?

Good, question. It should compile and work with the .veml files in examples.
I don't think it works with kdenlive right now. Before it makes sense to go 
for synchronisation with kdenlive, I have to rethink the veml for the 
effects/transitions. in 00-03-devel you can actually overlay text on the 
video (with odd colors though ;-)

> I think the important thing here is that piave should be able to read a
> multitude of formats, and export them to dv.

This is actually exactly what I _dont_ think. There is already 'transcode' to 
do that. the beauty of kdenlive is, that it's only a GUI. A small dialog to 
deploy transcode is by far better than reinventing the wheel inside piave. 
reading "a multitude" of fileformats is a tremendous effort. And exporting 
them to DV is not even possible, since DV only supports PAL and NTSC (4:3 and 
16:9) resolution. MPEG and AVI streams come with a arbitrary resolutions and 
fps (sometimes even with frames of different length, that happens when some 
programs transform NTSC<->PAL, they produce a short frame once in a while)

Can you give me a use case where somebody might want to _edit_ a video file 
which is not in DV or MPEG? I just cannot think of a case where somebody 
might want to do that.

I think we can do three things, one after the other, but eventually all of the 
three:

1)  handle DV (raw or in AVI-/Quicktime-containers)
    ->  raw and avi is already working and kino can to .mov so I can 
        steal it ;-)
    ->  this will be the "recommended" format since it is the most reasonable
        format to edit your video in.

2)  since 1) cannot handle a lot of input formats we might pick a second
    format which can be edited. I would vote for MPEG-2 (TS). It is wide 
    spread and people need it for DVDs anyway. New digi cams even use MPEG-2 
    to save their video (MicoMV format). It can handle any resolution/FPS.
    It can be decoded with reasonable amount of computing power, which is 
    really an issue when scanning through a file back and forth (rather than
    just playing it).
    A large variety of 'transcode' like tools canhelp you to convert whatever
    source you have to MPEG-2 (this could even be done inside the kdenlive 
    GUI)

3)  support a library which can read many formats, so "import" step of 
    converting to MPEG. I cannot imagine, that it will ever be possible to
    edit an DivX file conveniently, neither does it make sense since the loss
    of quality is huge and when editing video, you usually always have the 
    source in either DV or MPEG.
    This might be enix, libavcodec or even gstreamer
    Anyway, I thnik it might at least be possible to cut away start and end 
    chunks from your DivX DVD rips (ala VirtualDUB).


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

Sure, exporting is a completely different issue. This can be done.

> 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 this kind of integration of conversion should be done at GUI level. 
Not inside piave.

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

Sounds good. I'll take that as a start.

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

Ok, I think KDE is so incredibly flexible, that there is not much of a 
difference between a seperate dialog and another tab, right?

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky          http://hep.phy.tu-dresden.de/~dubitzky
 e-mail:         Rolf.Dubitzky at Physik dot TU-Dresden dot de
***************************************************************