[Kdenlive-devel] piave: AVI DV support

[Jason Wood]

On Sunday 15 June 2003 18:22, Rolf Dubitzky wrote:
> > 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.

One issue with embedding things directly in the gui is that it breaks the 
'client-server' approach that we currently have - the ultimate aim is to have 
some sort of asset management server that will take care of knowing where 
files are and potentially generating small-scale versions of them for remote 
editing (just a very longterm idea at the moment, let's say you have a 'home 
base' where you store all of your files and render them. You want to be able 
to edit from a seperate computer, but the connection isn't fast enough to be 
able to edit full-version files. The solution is that an asset management 
server allows you to request the files you want, and would convert them to 
some low-bandwidth, editable equivalent. Then, once you are happy with the 
edit, the VEML file would be sent back to the asset management server, which 
would create the final render from the original versions of the file).

Actually though, perhaps the point here is that in the future we will have a 
number of different apps that connect to the gui like piave does - then 
conversion work can be done in there rather than in piave. That would allow 
the gui to remain completely unaware of what is going on 'behind the scenes' 
of the edit, whilst allowing piave to remain focused on video editing 
operations.

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

Out of interest, what about MJpeg? What screen ratios/framerates does it 
support?

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

(by edit I am assuming here that it is allowable to convert a file to dv/mpeg 
before editing).

Well, the simplest case would be where people are experimenting with video 
editing in a non-proffesional capacity.

Let's take a high school kid who wants to make his own mtv-style music show. 
He's got a computer with firewire, and can use his parent's digital camera. 
He's relying on downloading videos off the web to put together his 
masterpiece, maybe video trailers off apples website, or music videos off 
gnutella/kazaa. 

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

Ok.

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

You could make the capture work as either a tab or a dialog with a little 
extra work (here, I mean a tab as in the way that all monitors, panels, etc. 
in kdenlive are tabs, and dialog to mean, for example, the render window).

There is very little difference in functionality between a modeless dialog and 
a KDockWidget as used in kdenlive, except that the KDockWidget is slightly 
more generalised - you can dock it next to other widgets, hide it, show it 
(err, well that's still an outstanding issue thinking about it). But they 
work in a slightly different way in code - although it might just be as 
simple as choosing which base class you want to use, I can't remember.

However, I have been trying to avoid modal dialogs in kdenlive, since it is 
annoying when they block the application until you close them :-) The only 
exceptions in kdenlive that I can think of at the moment are save/load and 
render dialogs.

Cheers,
Jason 

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