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