From: Rolf D. <dub...@pk...> - 2003-01-25 18:41:24
|
Hi, I have commit a huge set of changes. This is not yet stable, but I want to let people see how the plugin based architecture looks like. from kdenlive point of view, there are not many new features, in contrary, some old things do not yet work, especially in context with kdenlive, but you can try out utils/pplay and utils/plistplugins. new: - PLUGINS !! all input and output streams, as well as all effects/transitions are now handled as loadable plugins. There are seven plugins already. Most important are: - InRawDVStream : use libdv read from raw DV files - OutSDLStream : use SDL to display video - gdk-pixbuf : This is the second _major_ change. I removed all dependencies to gdk-pixbuf. Frame buffers are now handled by piave. not yet: - OSS sound output plugin. this is easy but I had no time yet to finish it. - write to raw dv file. - no reply to kdenlive 'getCaps' yet, but this is now possible. It wasn't even implementable before. - communication with kdenlive might be screwed up at the moment. I suggest a clean new checkout. There is almost no file in it's old place anyway ;-) Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Jason W. <jas...@bl...> - 2003-01-26 02:21:48
|
On Saturday 25 Jan 2003 6:41 pm, Rolf Dubitzky wrote: > Hi, > > I have commit a huge set of changes. This is not yet stable, but I want to > let people see how the plugin based architecture looks like. from kdenlive > point of view, there are not many new features, in contrary, some old > things do not yet work, especially in context with kdenlive, but you can > try out utils/pplay and utils/plistplugins. > <snip> > > I suggest a clean new checkout. There is almost no file in it's old place > anyway ;-) Great work! And I can confirm, it doesn't work with Kdenlive at all at the moment ;-) It makes me feel guilty for not doing much development in the last couple of days :-) I have been relaxing a little whilst I sort out in my head how to code the file dialog(s) properly - it's coming along slowly but surely, expect something in about a week, I should say, maybe sooner if I find the time and it all suddenly slots into place. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: <r....@t-...> - 2003-01-26 09:27:55
|
Am Samstag 25 Januar 2003 07:41 nachmittags/abends schrieb Rolf Dubitzky: > Hi, > > I have commit a huge set of changes. This is not yet stable, ... Yes, make failed here: creating config.h make all-recursive make[1]: Entering directory `/home/booker/cvs/piave' Making all in libpiave make[2]: Entering directory `/home/booker/cvs/piave/libpiave' /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I/usr/local/include/libxml++-1.0 -I/usr/local/lib/libxml++-1.0/include -I/usr/include/libxml2 -c piave_base.cc mkdir .libs c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I/usr/local/include/libxml++-1.0 -I/usr/local/lib/libxml++-1.0/include -I/usr/include/libxml2 -Wp,-MD,.deps/piave_base.pp -c piave_base.cc -fPIC -DPIC -o .libs/piave_base.lo piave_base.cc: In static member function `static void PIAVE::Global::printBackTrace()': piave_base.cc:148: `cerr' undeclared (first use this function) piave_base.cc:148: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [piave_base.lo] Error 1 make[2]: Leaving directory `/home/booker/cvs/piave/libpiave' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/booker/cvs/piave' make: *** [all-recursive-am] Error 2 [booker@linux piave]$ > I suggest a clean new checkout. There is almost no file in it's old place > anyway ;-) EVEN after a new checkout! Could this be caused by gcc3.2 ? [booker@linux piave]$ gcc --version gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-1mdk) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [booker@linux piave]$ greetings Reinhard |
From: Rolf D. <dub...@pk...> - 2003-01-26 11:54:58
|
On Sunday 26 January 2003 10:27 am, booker wrote: > Am Samstag 25 Januar 2003 07:41 nachmittags/abends schrieb Rolf Dubitzky: > > Hi, > > > > I have commit a huge set of changes. This is not yet stable, ... > > Yes, make failed here: fixed ;-) Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: <r....@t-...> - 2003-01-26 21:20:34
|
Am Sonntag 26 Januar 2003 12:54 nachmittags/abends schrieb Rolf Dubitzky: > On Sunday 26 January 2003 10:27 am, booker wrote: > > Am Samstag 25 Januar 2003 07:41 nachmittags/abends schrieb Rolf Dubitzky: > > > Hi, > > > > > > I have commit a huge set of changes. This is not yet stable, ... > > > > Yes, make failed here: > > fixed ;-) Sorry, now it stopped here: (But I don't know if this is normal at this point) rm -f .libs/libdv_codec.lo c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -g -O2 -I/usr/local/include/libxml++-1.0 -I/usr/local/lib/libxml++-1.0/include -I/usr/include/libxml2 -Wp,-MD,.deps/libdv_codec.pp -c libdv_codec.cc -fPIC -DPIC -o .libs/libdv_codec.lo libdv_codec.cc:458: default argument given for parameter 2 of `void PIAVE::LibDVEncoder::encodeVideo(PIAVE::Frame&, uint8_t* = 0)' libdv_codec.hh:121: after previous specification in `virtual void PIAVE::LibDVEncoder::encodeVideo(PIAVE::Frame&, uint8_t* = 0)' libdv_codec.cc:464: default argument given for parameter 2 of `void PIAVE::LibDVEncoder::encodeAudio(PIAVE::Frame&, uint8_t* = 0)' libdv_codec.hh:122: after previous specification in `virtual void PIAVE::LibDVEncoder::encodeAudio(PIAVE::Frame&, uint8_t* = 0)' make[4]: *** [libdv_codec.lo] Error 1 make[4]: Leaving directory `/home/booker/cvs/piave/plugins/iostream/rawdv' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/booker/cvs/piave/plugins/iostream' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/booker/cvs/piave/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/booker/cvs/piave' make: *** [all-recursive-am] Error 2 [booker@linux piave]$ greetings Reinhard |
From: Rolf D. <dub...@pk...> - 2003-01-26 21:23:11
|
On Sunday 26 January 2003 10:20 pm, booker wrote: > Am Sonntag 26 Januar 2003 12:54 nachmittags/abends schrieb Rolf Dubitzky: > > On Sunday 26 January 2003 10:27 am, booker wrote: > > > Am Samstag 25 Januar 2003 07:41 nachmittags/abends schrieb Rolf Dubitzky: > > > > Hi, > > > > > > > > I have commit a huge set of changes. This is not yet stable, ... > > > > > > Yes, make failed here: > > > > fixed ;-) > > Sorry, now it stopped here: > (But I don't know if this is normal at this point) Caught in the act ;-) I'll give a note when I'm done. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Rolf D. <dub...@pk...> - 2003-01-26 21:42:20
|
On Sunday 26 January 2003 10:20 pm, booker wrote: > Sorry, now it stopped here: > (But I don't know if this is normal at this point) Err.. while checking I realized, that this bug was not new. Somewhow all my compilers don't complain about that line, which is also what the C++ standard says. What compiler are you using? Well, anyway, I fixed it, thanx for testing Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Rolf D. <dub...@pk...> - 2003-01-26 14:50:23
|
On Sunday 26 January 2003 03:25 am, Jason Wood wrote: > Great work! And I can confirm, it doesn't work with Kdenlive at all at the > moment ;-) Actually I am not sure why. For me, kdenlive sends a <getCapabilities> request, and then locks up. Doesn't even send <createXWindow> ... > I have been relaxing a little whilst I sort out in my head how > to code the file dialog(s) properly - it's coming along slowly but surely, > expect something in about a week, I should say, maybe sooner if I find the > time and it all suddenly slots into place. ;-) To get you something to test with, I implemented some replies to <getCapabilities> so you can try to parse those ;-) (latest HEAD) I think it looks quite good. I closely followed your suggestion. One might remove the <effects> <inputs> <outputs> <codecs> tags. They are redundant, since the daughtere elemenet also starts with <effect> <instream> <outstream>. The syntax of the iostram<->codec description is not yet finished, but it's pretty obvious how it should look like, I think. (the order of the XML attributes is out of my control, it looks alphabetical, but doesn't matter anyway) What people you think? It pretty much reflects the current status of piave. <capabilities> <renderer name="PIAVE" version="0.2.9"> <author email="ro...@du..." name="Rolf Dubitzky" /> <about> blah... video render engine.. blah.. blah... GPL... blah... cool.... blah... home: www.dubitzky.de/piave (c) 2003 Rolf Dubitzky </about> </renderer> <general oneTrackEffects="yes" subFrameEditing="no" twoTrackEffects="yes" /> <effects> <effect name="AlphaBlend"> <input audio="yes" name="A" video="yes" /> <input audio="yes" name="B" video="yes" /> <parameter max="1.0" min="0.0" name="fade" type="double"> Controls the transparency of video B. At 0.0, video A is completely on screen. At 1.0, video B is completely visible. </parameter> <preset name="crossfade"> <fade> <keyframe time="0.0" value="0.0" /> <keyframe time="1.0" value="1.0" /> </fade> </preset> <preset name="overlay"> <fade> <keyframe time="0.0" value="0.5" /> <keyframe time="1.0" value="0.5" /> </fade> </preset> <preset name="inandout"> <fade> <keyframe time="0.0" value="0.0" /> <keyframe time="0.2" value="1.0" /> <keyframe time="0.8" value="1.0" /> <keyframe time="1.0" value="0.0" /> </fade> </preset> <about> This binary operator can be used to overlay a still images, fade in text, cross fade transitions, etc, etc... </about> </effect> <effect name="InvertFilter"> <input input="A" video="yes" /> <about> This filter is a simple color inversion, no parameters. </about> </effect> </effects> <inputs> <instream name="InRawDVStream"> <file> <container extension=".dv" format="rawdv" /> <videocodecs> <libdv_decoder /> </videocodecs> <audiocodecs> <libdv_decoder /> </audiocodecs> </file> <about> Can read raw DV files. </about> </instream> </inputs> <outputs> <outstream name="OutRawDVStream"> <file> <container extension=".dv" format="rawdv" /> <videocodecs> <libdv_encoder /> </videocodecs> <audiocodecs> <libdv_encoder /> </audiocodecs> </file> <about> Can write raw DV files. </about> </outstream> <outstream name="SDLStream"> <screen> <X11 fallback="rgb" visual="xv" /> <X11 visual="rgb" /> </screen> <about> Use SDL to display video. Uses xv overlay if available. </about> </outstream> </outputs> <codecs> <decoder name="libdv_decoder"> <format fourcc="DVSD" /> <format fourcc="dvsd" /> <format fourcc="DVCS" /> <format fourcc="dvcs" /> <format fourcc="dvc" /> <about> This codec uses libdv to decode DV video. </about> </decoder> <encoder name="libdv_encoder"> <about> This codec uses libdv to encode DV video. </about> </encoder> </codecs> </capabilities> Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Rolf D. <dub...@pk...> - 2003-01-26 14:55:16
|
On Sunday 26 January 2003 03:50 pm, Rolf Dubitzky wrote: > What people you think? err.. -> "What do people think?" ;-) Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Jason W. <jas...@bl...> - 2003-01-26 15:17:12
|
On Sunday 26 Jan 2003 2:50 pm, Rolf Dubitzky wrote: > On Sunday 26 January 2003 03:25 am, Jason Wood wrote: > > Great work! And I can confirm, it doesn't work with Kdenlive at all at > > the moment ;-) > > Actually I am not sure why. For me, kdenlive sends a <getCapabilities> > request, and then locks up. Doesn't even send <createXWindow> ... Ah, I think I know what is causing this. Are you still running piave from a seperate console? You can still do this, but Kdenlive is now running *3* instances of piave. They are allocated the following ports : 6100 : Document renderer - handles requests for file lengths, and exporting. 6101 : Workplace Monitor - Displays and previews the complete timeline. 6102 : Clip Monitor - Handles the display of a single clip, including for resizing on the timeline. Whilst all renderers will be asked for their capabilities, only the workplace and clip monitor actually get an create window request - the document renderer is for background tasks only. If this setup changes, I'll let you know. In the meantime, start piave with the relevant port to test whichever window you want to test. > > I have been relaxing a little whilst I sort out in my head how > > to code the file dialog(s) properly - it's coming along slowly but > > surely, expect something in about a week, I should say, maybe sooner if I > > find the time and it all suddenly slots into place. > > ;-) To get you something to test with, I implemented some replies to > <getCapabilities> so you can try to parse those ;-) (latest HEAD) Compiling now, thanks that should help me to put together the "loading" code for the dialogs, rather than hand-coding an example ;-) From a first look, the capabilities look good, I'll comment some more when I have had chance to study it a little. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <dub...@pk...> - 2003-01-26 15:28:36
|
On Sunday 26 January 2003 04:20 pm, Jason Wood wrote: > On Sunday 26 Jan 2003 2:50 pm, Rolf Dubitzky wrote: > > On Sunday 26 January 2003 03:25 am, Jason Wood wrote: > > > Great work! And I can confirm, it doesn't work with Kdenlive at all at > > > the moment ;-) > > > > Actually I am not sure why. For me, kdenlive sends a <getCapabilities> > > request, and then locks up. Doesn't even send <createXWindow> ... > > Ah, I think I know what is causing this. Are you still running piave from a > seperate console? You can still do this, but Kdenlive is now running *3* > instances of piave. They are allocated the following ports : Why shouldn't I run the first instance on a seperate console? It worked a while ago. The irst instance (6100) was catched from the console and the others started seperately. And also I tried without manual startup and .. no difference. It is absolutely necessary, that I can start piave manually from a console. > 6100 : Document renderer - handles requests for file lengths, and > exporting. Ahh, that's why this instance doesn't get a createXWindow. ;-) > 6101 : Workplace Monitor - Displays and previews the complete > timeline. 6102 : Clip Monitor - Handles the display of a single clip, > including for resizing on the timeline. > > Whilst all renderers will be asked for their capabilities, only the > workplace and clip monitor actually get an create window request - the > document renderer is for background tasks only. > > If this setup changes, I'll let you know. In the meantime, start piave with > the relevant port to test whichever window you want to test. ok. Are you sure that we need all those instances running? I think the sepearation might make sense from an abstract point of view, but in reality, we'll have one piave _with_ xv overlay which will be fast, and all the other will have to use rgb, which is slow. Please keep that in mind. Two equal windows, both setup to play video in realtime are not possible. > Compiling now, thanks that should help me to put together the "loading" > code for the dialogs, rather than hand-coding an example ;-) great ;-) Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Jason W. <jas...@bl...> - 2003-01-26 15:46:17
|
On Sunday 26 Jan 2003 3:28 pm, Rolf Dubitzky wrote: > > Whilst all renderers will be asked for their capabilities, only the > > workplace and clip monitor actually get an create window request - the > > document renderer is for background tasks only. > > > > If this setup changes, I'll let you know. In the meantime, start piave > > with the relevant port to test whichever window you want to test. > > ok. Are you sure that we need all those instances running? I think the > sepearation might make sense from an abstract point of view, but in > reality, we'll have one piave _with_ xv overlay which will be fast, and all > the other will have to use rgb, which is slow. Please keep that in mind. > Two equal windows, both setup to play video in realtime are not possible. The code is already (partially) in place to swap the windows on request, so that the active playback window is always the one with xv. At this point the two monitor processes will probably change name to "primary" and "secondary" or something similar. At the moment, both are RGB simply so I can get the rest of the architecture in place first before adding the swapping code permanently - it's a little hackish at the moment. Why a second instance of Piave for the inactive monitor? There are a couple of reasons. When you have both monitors on screen at the same time, we want to maintain the images in both windows, no matter which is playing. To do this, we either have to have a second instance of piave displaying the inactive window, or we display a bitmap... which would involve grabbing the picture display from piave somehow, probably via tcp ;-) As for the document renderer... I'm not sure if that is needed yet, it depends on exactly how I implement background rendering in the future. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <dub...@pk...> - 2003-01-26 15:50:32
|
On Sunday 26 January 2003 04:49 pm, Jason Wood wrote: > On Sunday 26 Jan 2003 3:28 pm, Rolf Dubitzky wrote: > The code is already (partially) in place to swap the windows on request, Ahh... ok... that sounds good. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Rolf D. <dub...@pk...> - 2003-01-26 19:12:56
|
On Sunday 26 January 2003 04:20 pm, Jason Wood wrote: > On Sunday 26 Jan 2003 2:50 pm, Rolf Dubitzky wrote: > > On Sunday 26 January 2003 03:25 am, Jason Wood wrote: > > > Great work! And I can confirm, it doesn't work with Kdenlive at all at > > > the moment ;-) Hi, I fixed a lot of things but I got stuck. piave now reacts to <creatWin..> but for some reason the window gets closed imediately. I am not sure why, or by whom. Maybe you have some idea? I commit all changes in a sec. I would be great if you could find out if it's kdenlive's or piave's fault (probably piave..) This led to some other considerations. You might want to try utils/pplay with all kinds of different dv formats (PAL/NTSC/4x3/16x9) and you will hopefully see that it not only works, but you also get the correct aspect ratio. In case of PAL this doesn't really matter, but in case of NTSC this makes a huge difference. Now, kdenlive should not create an XWindow without knowing the aspect ratio of the target format. Already now you can request a XWindow with specific size. just add width="123" height="345" to the <creatXWin..> command, _but_ it makes no sense to do that before the user has specified the target format (or kdenlive knows the aspect of the input file it wants to display). piave uses 4x3 by default and will open a windows with half DV PAL size. I think kdenlive can live with that for now (will notwork for wide screen, but for PAL and NTSC), but you can prepare to change that. I would be cool to have something like "Use <some_input_file> format as target format" next to a manual selection. <getFileProp..> returns alread something like: <stream filename="../samples/4x3-PAL.dv"> <container format="rawdv" /> <videocodec aspect="1.333333" format="DV" fps="25.000000" height="576" system="PAL" width="720" /> <audiocodec emphasis="off" format="PCL" frequency="32000" num_channels="2" quantization="12" sampling="2" /> </stream> Note that width/height != aspect ! We have to think about how to communicate the render size as soon as we have effects. The render size might be different from the source size for preview mode (samller -> faster/poorer) . Also, the '-f rgb' option is gone. You can specify the target with the <creatWin...> command with <creat... visual="rgb" > . The default is "xv" and piave will use rgb automatically if no yuv overlay is available. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Rolf D. <dub...@pk...> - 2003-01-26 19:20:09
|
On Sunday 26 January 2003 08:12 pm, Rolf Dubitzky wrote: > Now, kdenlive should not create an XWindow without > knowing the aspect ratio of the target format. Hmm... thinking of that... I think that it might make more sense, if piave just adjusts the size of the window to the aspect of the input file. The we could move the specification of the target size/aspect to the scenelist specification.... Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Jason W. <jas...@bl...> - 2003-01-26 19:51:27
|
On Sunday 26 Jan 2003 7:20 pm, Rolf Dubitzky wrote: > On Sunday 26 January 2003 08:12 pm, Rolf Dubitzky wrote: > > Now, kdenlive should not create an XWindow without > > knowing the aspect ratio of the target format. > > Hmm... thinking of that... I think that it might make more sense, if piave > just adjusts the size of the window to the aspect of the input file. The we > could move the specification of the target size/aspect to the scenelist > specification.... Ok, after answer your previous post with words to that effect ;-) I think it would still be useful to have the "set target aspect ratio" that was suggested. Consider that you are creating a PAL project out of both NTSC and PAL footage (can piave do this now? well, let's assume it can for the moment). We don't want to have the size of the window jumping around at each cut, because when we render the footage down, that isn't what will happen - it will be exported to the PAL resolution. So, we should specify that we want all footage to be displayed at the PAL aspect ratio so that we can see what it will look like. Does that make sense, or am I missing something? Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <dub...@pk...> - 2003-01-26 20:07:53
|
On Sunday 26 January 2003 08:54 pm, Jason Wood wrote: > Consider that you are creating a PAL project out of both NTSC and PAL > footage (can piave do this now? no. The problem is just, that I do not yet have inplemented (read: stolen) a algorithm to rescale YUV images. As soon as I have that it will be possible. > We don't want to have the size of the window jumping around at each cut, > because when we render the footage down, that isn't what will happen - it > will be exported to the PAL resolution. So, we should specify that we want > all footage to be displayed at the PAL aspect ratio so that we can see what > it will look like. > > Does that make sense, or am I missing something? No. That is what I meant with specifying the target format before the <setScenelist> (not every time of course). Something like: <setTargetFormat> <targetformat> <video fps="25.0" width="123" height="123" aspect="1.4" /> <audio frequency="231234" ... /> </targetformat> </setTargetFormat> In case of a single clip in the scenelist, I could use the parameters of that clip as default. Makes clip previews easier. -- Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Jason W. <jas...@bl...> - 2003-01-26 19:46:23
|
On Sunday 26 Jan 2003 7:12 pm, Rolf Dubitzky wrote: > This led to some other considerations. You might want to try utils/pplay > with all kinds of different dv formats (PAL/NTSC/4x3/16x9) and you will > hopefully see that it not only works, but you also get the correct aspect > ratio. In case of PAL this doesn't really matter, but in case of NTSC this > makes a huge difference. Now, kdenlive should not create an XWindow without > knowing the aspect ratio of the target format. Already now you can request > a XWindow with specific size. just add width="123" height="345" to the > <creatXWin..> command, Urk, no, I don't like this. The window size should not be specified by kdenlive, but rather by the user when he resizes the window. Piave should automatically set itself to a draw area that works (i.e., maintains aspect ratio). Does piave recieve window resize (x11, not VEML) events at the moment? If it doesn't, then that is where the problem lies (either that kdenlive isn't telling piave to resize the window properly, or that SDL has been set up with a fixed window size). (On a similar note, I am unsure as to why Kdenlive currently doesn't allow you to "scale down" the video window, even when the piave instance that was contained within it dies. I'm looking into this.) We may need to add some options - for instance, should the renderer maintain aspect ratio? And should the renderer resize to fit the window, or remain at a fixed (and specified) resolution? This would be useful for e.g. maintaining half-dv image size. > _but_ it makes no sense to do that before the user > has specified the target format (or kdenlive knows the aspect of the input > file it wants to display). Ok, I can understand this problem, but I consider it unrelated to the problem of window size - I think we need a command for "set target format" or "set aspect ratio", I think. In the case of the clip monitor, it could vary depending on what clip is displaying - consider for example if you want to see a 'clip' of a 4096x768.png (say your going to add an effect to it so you can pan around it as part of your pal video)? It doesn't make sense to have to destroy the video window and recreate it to be able to achieve this, nor would you want the aspect ratio to be displayed incorrectly. > piave uses 4x3 by default and will open a > windows with half DV PAL size. I think kdenlive can live with that for now > (will notwork for wide screen, but for PAL and NTSC), but you can prepare > to change that. I would be cool to have something like "Use > <some_input_file> format as target format" next to a manual selection. > <getFileProp..> returns alread something like: Yes, this is what I agree with. > <stream filename="../samples/4x3-PAL.dv"> > <container format="rawdv" /> > <videocodec aspect="1.333333" format="DV" > fps="25.000000" height="576" > system="PAL" width="720" /> > <audiocodec emphasis="off" format="PCL" frequency="32000" > num_channels="2" quantization="12" > sampling="2" /> > </stream> > > Note that width/height != aspect ! Something I have just noticed : that container "contains" the videocodec and audio codec, so can you change the xml to reflect that? i.e. : <stream filename="../samples/4x3-PAL.dv"> <container format="rawdv"> <videocodec aspect="1.333333" format="DV" fps="25.000000" height="576" system="PAL" width="720" /> <audiocodec emphasis="off" format="PCL" frequency="32000" num_channels="2" quantization="12" sampling="2" /> </container> </stream> > We have to think about how to communicate the render size as soon as we > have effects. The render size might be different from the source size for > preview mode (samller -> faster/poorer) . Ok, I've got a little bit of catching up in Kdenlive to do first though :-) > Also, the '-f rgb' option is gone. You can specify the target with the > <creatWin...> command with <creat... visual="rgb" > . The default is > "xv" and piave will use rgb automatically if no yuv overlay is available. Ok, that's good. Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <dub...@pk...> - 2003-01-26 19:57:27
|
On Sunday 26 January 2003 08:49 pm, Jason Wood wrote: > On Sunday 26 Jan 2003 7:12 pm, Rolf Dubitzky wrote: > Urk, no, I don't like this. The window size should not be specified by > kdenlive, but rather by the user when he resizes the window. Yes, I agree, but at least the initial size should be set. there is just not enough room for two full DV pictures on the desktop ;-) > Piave should > automatically set itself to a draw area that works (i.e., maintains aspect > ratio). Does piave recieve window resize (x11, not VEML) events at the > moment? Yes, but I ignore it. This is not so simple. kdenlive let's the user resize the window al the time. I don't like that. resizeing means allocating new memory mappings and overlay port. That's not a cheap operation. I'd rather like some dialog choose image size x2.0 x1.0 or x0.5 and then let the window stay that size, not resize it with the mouse. > (On a similar note, I am unsure as to why Kdenlive currently doesn't allow > you to "scale down" the video window, even when the piave instance that was > contained within it dies. I'm looking into this.) The piave window is not resizeable (as replied to createWindow). > We may need to add some options - for instance, should the renderer > maintain aspect ratio? And should the renderer resize to fit the window, or > remain at a fixed (and specified) resolution? This would be useful for e.g. > maintaining half-dv image size. Yes, I like that better. spezify half/full/double size somewhere and then stay that way. > Something I have just noticed : that container "contains" the videocodec > and audio codec, so can you change the xml to reflect that? i.e. : hmm.. ok. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |
From: Jason W. <jas...@bl...> - 2003-01-26 20:26:43
|
On Sunday 26 Jan 2003 7:57 pm, Rolf Dubitzky wrote: > On Sunday 26 January 2003 08:49 pm, Jason Wood wrote: > > On Sunday 26 Jan 2003 7:12 pm, Rolf Dubitzky wrote: > > > > Urk, no, I don't like this. The window size should not be specified by > > kdenlive, but rather by the user when he resizes the window. > > Yes, I agree, but at least the initial size should be set. there is just > not enough room for two full DV pictures on the desktop ;-) Oh, yes I know that - hopefully though, window size should be specified and set during the loading of layouts (once it is implemented). > > > Piave should > > automatically set itself to a draw area that works (i.e., maintains > > aspect ratio). Does piave recieve window resize (x11, not VEML) events at > > the moment? > > Yes, but I ignore it. This is not so simple. kdenlive let's the user resize > the window al the time. I don't like that. resizeing means allocating new > memory mappings and overlay port. That's not a cheap operation. I'd rather > like some dialog choose image size x2.0 x1.0 or x0.5 and then let the > window stay that size, not resize it with the mouse. How expensive an operation is it, though? Does it take seconds, milliseconds, nanoseconds... ? Consider that once layouts are in place, the user will : 1. layout the app how they want it. 2. Use the app. I am not expecting the user to be sitting there resize the window whilst it is playing and complaining about how slow everything starst going ;-) Consider it to be a pretty-much one-off occurance, it doesn't matter if it is slow as long as it's not *too* slow (I'd say 30 seconds would be excessive). Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk |
From: Rolf D. <dub...@pk...> - 2003-01-26 20:32:17
|
On Sunday 26 January 2003 09:29 pm, Jason Wood wrote: > How expensive an operation is it, though? Does it take seconds, > milliseconds, nanoseconds... ? > Consider that once layouts are in place, the > user will : > > 1. layout the app how they want it. > 2. Use the app. > > I am not expecting the user to be sitting there resize the window whilst it > is playing and complaining about how slow everything starst going ;-) > > Consider it to be a pretty-much one-off occurance, it doesn't matter if it > is slow as long as it's not *too* slow (I'd say 30 seconds would be > excessive). It's not that slow, but if you resize the kdenlive window with the mouse (and users _will_ do tha very frequently), I get thousands of resize events. I have to prevent from really resizeing every time. I'll check it out when I have time. Up to then we will have to live with the windowsize kdenlive requests or what is in the clip to show. Cheers, Rolf *************************************************************** Rolf Dubitzky e-mail: Rolf.Dubitzky@Physik.TU-Dresden.de s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ *************************************************************** |