Re: [CinCVS] theme S.U.V. not found
On Saturday 28 April 2007 14:07, Graham Evans wrote: In this case, remove cputest.o (and/or cputest.lo), then build ffmpeg with different optimizations. Like: $ rm ffmpeg/libavcodec/cputest.*o $ make CFLAGS='-O0 -g' okay tried all that. Except I found deleting the files had no effect - they were just recreated each time. that's the point - when they are recreated, then with the altered optimization flags. From your message I assume that you got the same error. Then take the other route: $ make -k CFLAGS='-O0 -g' # this errors out in fdct_mmx.c with operands invalid for `pshufw' $ rm quicktime/ffmpeg/libavcodec/i386/fdct_mmx.*o $ make CFLAGS='-O2 -g' (It seems that this file wants to be compiled with some different sort of optimization.) BTW, I just noticed that the build flags of quicktime/ffmpeg/libavcodec/i386/ include -O3. Try removing that from Makefile.am - it is needed on i*86, but may not be needed on x86_64. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
On Thursday 26 April 2007 08:10, Graham Evans wrote: /usr/bin/ld: ffmpeg/libavcodec/.libs/libavcodec.a(cputest.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ffmpeg/libavcodec/.libs/libavcodec.a(cputest.o): could not read symbols: Bad value collect2: ld returned 1 exit status In this case, remove cputest.o (and/or cputest.lo), then build ffmpeg with different optimizations. Like: $ rm ffmpeg/libavcodec/cputest.*o $ make CFLAGS='-O0 -g' BTW, to the best of my knowledge, dynamic linking does *not* require -fPIC! It just so happens that if you compile with -fPIC then some amount of memory can be saved if the dynamic object is shared by different processes. Which is an unlikely situation for all dynamic objects that Cinelerra loads. For this reason, I suggested to configure --without-pic. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] theme S.U.V. not found
On Wednesday 25 April 2007 17:02, Graham Evans wrote: It seems all these problems have come up before but I can't find the solutions. Apparently the themes aren't building properly because of the static linking options I've used in my configure line. But I can't get a successful build without those options... Right, you can't build cinelerra statically (--disable-shared --enable-static) You can try to build the internal ffmpeg with different optimization options like this: $ make terminates with an error $ cd quicktime/ffmpeg $ make clean $ make CFLAGS='-O0 -g' hopefully works... $ cd ../.. make Try different optimization levels in CFLAGS. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] build failure svn 1008
On Wednesday 25 April 2007 10:50, Graham Evans wrote: so the final steps were ./autogen.sh ./configure --with-pic --disable-shared --enable-static make sudo make install All the configure flags turned out to be neccessary for a successful build. But...a new problem - cinelerra won't run. It says themes are missing... See my new thread: [CinCVS] theme S.U.V. not found. You can also try this (before you try the suggestion in my answer to this other thread): ./configure --without-pic There's no point in compiling the shared objects --with-pic because they aren't going to be shared (unless you run several instance of cinelerra, but then your worries are certainly not those 5MB that you could have saved). -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Compilation options
On Tuesday 17 April 2007 10:59, Philippe Ribet wrote: Hello, It looks like cinelerra is compiled without OpenGL option.Cinelerra's documentation advise to use OpenGL as many effects can be rendered in real time thanks to computing done by the graphic chip instead of the main processor. Is it by intention that OpenGL is not activated? If you ask so: yes. ;) In order to have OpenGL support, you need Nvidia drivers on the machine that *compiles* the program. A version with OpenGL enabled will not work on a machine without Nvidia drivers. Draw your conclusions. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Weird effect plugin problem
On Wednesday 11 April 2007 21:57, Richard Rasker wrote: Hi all, Something weird happened, quite out of the blue: since a few days, Cinelerra can't open about half the effect plugins on the AMD64 box (Mandriva 2007). This is what the command line says: $ cinelerra Cinelerra 2.1CV (C) 2006 Heroine Virtual Ltd. Compiled on za nov 18 00:18:19 CET 2006 Cinelerra is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. There is absolutely no warranty for Cinelerra. PluginServer::open_plugin: /usr/local/lib/cinelerra/brightness.so: undefined symbol: glUseProgram PluginServer::open_plugin: [etc] Now everything was fine until at most a week ago; the only thing that may have caused this, is a software update - but I don't recall any video driver stuff being part of this update. So you have compiled cinelerra yourself? With OpenGL support? Most likely you have NVidia hardware. Then you upgraded the software, but downgraded your OpenGL from NVidia to MESA. Most likely. If you now have a not too recent MESA, say something before 6.5, you don't have OpenGL 2.0 support, hence, no glUseProgram. Sort out the libGL.so.* that you find on your system. Upgrade your NVidia drivers, too. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Build System enhancement (any helpers?)
On Thursday 05 April 2007 17:41, Christian Thaeter wrote:
I started to transform the recursive ('SUBDIRS') Makefile.am builds into
'include' statements (see 'info automake' chapter 7.3). The idea behind
this is to make rebuilds much faster and more sane and utilize a distcc
cluster much better. The rationale about is, that a distcc build here
will waste about 50% of its time in doing serialized subdir builds in
the plugin folder and even minimal changes at the code will cause a time
consuming full subdirs traversal.
The only directory that really needs some fixing is the plubins/ directory.
I'd really appreciate some sort of fix there. I've done some work in this
direction myself, by building the plugins from plugins/Makefile.am instead of
from individual Makefile.ams. But there were some obstacles that I didn't
take the time to clean out...
If you can come up with patchex that addresses the plugins directory, I'll
gladly apply them.
Please avoid any exotic features (of automake) and don't expect everybody to
have latest and hottest automake.
-- Hannes
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Mutex (JACK support...)
On Saturday 31 March 2007 12:13, Markku Linnoskivi wrote: Now that I got the compiling work, my code won't compile 'cause the compiler complains about missing Mutex definition: audiojack.C: In constructor 'AudioJack::AudioJack(AudioDevice*)': audiojack.C:106: error: invalid use of undefined type 'struct Mutex' ../guicast/mutex.inc:4: error: forward declaration of 'struct Mutex' audiojack.C: In destructor 'virtual AudioJack::~AudioJack()': audiojack.C:117: error: invalid use of undefined type 'struct Mutex' ../guicast/mutex.inc:4: error: forward declaration of 'struct Mutex' audiojack.C:124: error: invalid use of undefined type 'struct Mutex' ../guicast/mutex.inc:4: error: forward declaration of 'struct Mutex' cinelerra/audiodevice.h includes mutex.inc and I include audiodevice.h so I should be able to use that, right? audioalsa.h/.C does the same. So whats the problem? At the top of audiojack.C add #include mutex.h Make sure all your #include lines are sorted alphabetically (that's just a style issue, not a technical requirement). -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [PATCH] make configure detect and work on amd64
On Tuesday 06 March 2007 21:04, Johannes Sixt wrote: On Tuesday 06 March 2007 00:44, [EMAIL PROTECTED] wrote: what about attached patch for the mmx part? Looks good. I'd appreciate to have this cross-checked by others with x86_64 hardware. Please test both --disable-mmx and --enable-mmx. The patch is now in SVN. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] JACK support
On Friday 30 March 2007 15:20, Markku Linnoskivi wrote: I've been working for a few hours on JACK output driver. Now I'd like to try to compile it. JACK need some libraries to be linked in the system. Thes can be included with: `pkg-config --cflags --libs jack` on the gcc command. Also cheking for the libraries can be done with: PKG_CHECK_MODULES(JACK, jack, HAVE_JACK=true, HAVE_JACK=false) (Taken from JACK web site) Now my problem is how to put those in the configure/Makefile? Also my code has #ifdef HAVE_JACK checks, so that variable should be defined. Put these lines into configure.in (before the end of the SOUND section, about line 110): AH_TEMPLATE(HAVE_JACK, [Define if you have JACK sound mixer library]) PKG_CHECK_MODULES(JACK, jack, [AC_DEFINE(HAVE_JACK)], :) AC_SUBST(JACK_CFLAGS) AC_SUBST(JACK_LIBS) Then use $(JACK_CFLAGS) and $(JACK_LIBS) in cinelerra/Makefile.am, just like OPENEXR_*, for example. You must make sure that config.h is included in all files that check for HAVE_JACK. Also if some one could tell me the file where the audio driver is selected, AudioLowLevel object is instanciated that is. AudioDevice::create_lowlevel() in cinelerra/audiodevice.C What was so difficult to find this function? -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] No compilation today :(
On Wednesday 28 March 2007 16:34, Hannu Vuolasaho wrote: ../quicktime/.libs/libquicktimehv.so: undefined reference to `x264_pixel_satd_16x8_ssse3' (etc) You compiled x264 yourself. You better find out which options you need so that the missing functions are compiled into libx264. Hint: It must have something to do with ssse3 ;) No? -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: Vs: Re: [CinCVS] Re: Cinelerra sound system?
On Wednesday 14 March 2007 11:05, [EMAIL PROTECTED] wrote: Could someone tell me where some writing to the audio device is done so I could understand the system better? Start looking in VirtualAConsole::process_buffer(), there is a call to renderengine-audio-write_buffer(). -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Why OpenGL does not affect rendering, It just accelerates playback?
May I ask why OpenGL does not affect rendering, It just accelerates playback? What is the reason? The reason is that by the time rendering takes place there is no guarantee that a connection to an X server is available. Think of renderfarms. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: Patch for cinelerra/fileyuv.C -- what am I doing wrong?
On Tuesday 13 March 2007 13:21, Jim Scott wrote: On 3/10/07, Jim Scott [EMAIL PROTECTED] wrote: I've never submitted a patch before and I'm not sure if this is the right spot. This patch removes the -hq setting from the default yuv4mpeg ffmpeg settings in cinelerra/fileyuv.C I don't think the -hq switch is supported by current versions of ffmpeg, so I think it makes sense to remove the setting. Could someone please let me know whether this is the wrong place to suggest a patch or whether the change is not acceptable? This is the right place to submit a patch. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] fixing cinelerra, using standard C++ libs etc.
On Wednesday 07 March 2007 19:25, Christian Thaeter wrote: Remove the Garbage collector in favor of boost::shared_ptr, the GC has some nasty bugs, partially together with threads. By replacing ALL Asset* with boost::shared_ptrAsset these should be fixed on expanse of some performance. Is boost::shared_ptr thread safe? If not, this replacement does not fix anything, in particular not the thread related bugs. Manage Assets in std::vectorboost::shared_ptr / std::listboost::shared_ptr. First things done: http://www.pipapo.org/gitweb?p=cinelerra/ct;a=shortlog;h=ct you might pull it with git git clone git://git.pipapo.org/git/cinelerra/ct or git clone git://repo.or.cz/cinelerra_cv/ct.git Replacing Asset* in parameter lists by Asset is certainly not worth it. You gain absolutely nothing, but only introduce a lot of unnecessary code changes. Please don't do that. If you want to change something to use std:: classes, start by replacing strings (char*) by std::string. But don't do that in one big sweep, be very selective which strings you replace. Start with the text in the Titler plugin (that's a real bug). Work your way through topics, eg. path names (which are easily overflown), other strings that are user input. Finally, user interface strings like menu titles. (At least) for the latter use a typedef because these strings are likely to be promoted to Unicode strings to better support non-latin UI languages. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: [Cinelerra-commits] right list
On Tuesday 06 March 2007 14:34, Mark Grieveson wrote: Hello. I'm wondering if I'm in the correct mailing list. Is this for users of cinelerra (in the same sense that the Debian User mailing list is for users of Debian) or am I in the wrong list (ie, a development list for programmers of something). If this isn't a user list, could someone direct me to one? I have a lot of questions. You want to go to this list: Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [PATCH] make configure detect and work on amd64
On Tuesday 06 March 2007 00:44, [EMAIL PROTECTED] wrote: what about attached patch for the mmx part? Looks good. I'd appreciate to have this cross-checked by others with x86_64 hardware. Please test both --disable-mmx and --enable-mmx. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [PATCH] make configure detect and work on amd64
On Saturday 17 February 2007 17:03, [EMAIL PROTECTED] wrote: Hi, trying to compile cinelerra on amd64 / ubuntu edgy i had some problems i wanted to use ffmpeg from the repositories, same for x264. with attached patch, * libmpeg3/video/mmxidct.S is only used on x86_32 * adds amd64 CFLAGS to use all amd64 features if configure is run with --enable-mmx * use libx264_pic if available instead of libx264 and if called with --with-pic Thanks, but: - There was talk recently that compilation fails on amd_64 unless --enable-mmx=no. Your patch sets it to 'yes' if --enable-mmx was not set. I had to fix this particular problem. Has something changed? See https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2007-January/009702.html http://repo.or.cz/w/cinelerra_cv.git?a=commitdiff;h=f7ca8d92e1c0cb0ef90cbc17506d388dd5cb0622 http://repo.or.cz/w/cinelerra_cv.git?a=commitdiff;h=052cb77e7d96c19ae260f696baa9d40c6e2313cc - Is libx264_pic a commonly used name or specific to ubuntu? - I'd like to move the x86_64 case above the powerpc case. Ok? - Adding all those optimization options, -funroll-loops -minline-all-stringops etc. to the default compile line is a big NO-NO. It may be convenient for you, but it is not good practice in general. Is there any harm done if I remove them? - You define an AM_CONDITIONAL named CPU_x86_64 that is not used anywhere. Ok to remove it? - The assignment libx264_pic=yes must read libx264=yes. I'll fix that. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] mpeg decoding leak crush
On Friday 09 February 2007 22:42, Scott C. Frase wrote: apply histogram and play 30s 1367MB quit cinelerra 1139MB That's good news. It means that cinelerra used only ~230MB. Everything else must be other applications or cached file data. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Multiple video cards
On Monday 12 February 2007 08:59, Matt Pfingsten wrote: It's 2AM here and I had a crazy idea/question. What would happen if I had multiple video cards installed on my system (like a dual monitor setup or something without dual-head cards). Would Cinelerra's OpenGL accelerated effects take advantage of all available GPU's or just the first one? It will use only one. Although I'm not entirely certain which one. I think it will be the one that displays the compositor. Note that OpenGL is used only during editing, not for rendering. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Creating DVD from Cinelerra: input source
On Friday 09 February 2007 10:47, Yannick Patois wrote: Johannes Sixt wrote: On Thursday 08 February 2007 13:20, Yannick Patois wrote: What I saw, when looking at the resulting m2v file, is (roughly) a 680x480 crop of the image not 704x576. I didnt went up to the DVD but I belive that the cropped area wont reapear... Some Equipment displays only a subpart of the theoretically possible image. Live with it. That doesn't change the math, but you have to be careful that you don't put important information (like titles) too far to the borders. The problem is that the certain device is both cinelerra (in its Composer window) and xine (after rendering a m2v file according to the manual). I just looked in the cinelerra project XML and read stuff like: VIDEO INTERPOLATION_TYPE=0 INTERPOLATE_RAW=1 WHITE_BALANCE_RAW=1 COLORMODEL=RGBA-8 Bit INTERLACE_MODE=BOTTOM_FIELD_FIRST CHANNELS=1 VCHANNEL_X_0=0 VCHANNEL_Y_0=0 FRAMERATE=25 FRAMES_PER_FOOT=16 OUTPUTW=720 OUTPUTH=576 ASPECTW=4 ASPECTH=3/VIDEO VIDEO HEIGHT=576 WIDTH=720 LAYERS=1 FRAMERATE=1 VCODEC=rlea VIDEO_LENGTH=-1 INTERLACE_AUTOFIX=1 INTERLACE_MODE=UNKNOWN INTERLACE_FIXMETHOD=DO_NOTHING REEL_NAME=cin REEL_NUMBER=0 TCSTART=0 TCEND=0 TCFORMAT=0/VIDEO So it seems that I did my configuration well for 720x576... Does it seems normal? Looks ok. I just tried this: - Created a circle with Gimp on a 720x540 canvas. - Resized that canvas to 720x576 and stored as png. (The Circle is now more a vertical ellipse, of course.) - Created a new PAL project in Cinelerra (720x576). - Loaded the png as resource only into Cinelerra. - Dragged the media onto the time line. - The composer now shows a perfect circle. Not a vertical ellipse. Not a horizontal ellipse. Nothing is cropped. No borders were added. I don't know what you did wrong. Note that I didn't care about the 720 vs. 704 pixel width for the moment. If I had cared, I would have scaled the original 720x540 canvas to 704x576 and _then_ added 8 pixels of blackness to the left and right. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] getting started - can't play edited clip - regular clip play stops working
On Monday 05 February 2007 21:00, Richard Rasker wrote: Some digging around in the sources seems to indicate that audioalsa.C contains the code for this; correct me if I'm totally wrong, but this code seems to process interrupt_workaround, the variable controlled through the GUI option. But lacking both sufficient C programming skills and a more complete overview of Cinelerra, I can't really trace what exactly happens here. The comments suggest some dirty tricks and/or trial-and-error-programming, though. The workaround was implemented by me. The option to disable it (actually enable it) was made by HV. See http://bugs.cinelerra.org/show_bug.cgi?id=153 Or am I wrong? If anyone is in the know, could we please sort out a universal solution that will satisfy all users, out of the box? It would be nice if this weird option could be sorted out and abolished. It's too much like this appears to work but don't ask me how, which is not good. Then again, this isn't exactly a pressing matter, merely annoying (although almost every newbie stumbles upon this one). The interesting thing would be if there are any ALSA users who do _not_ need this option. The hardware/OS/ALSA version combination may give some clues where the workaround is needed. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] constant hangs on HDV project
On Tuesday 06 February 2007 02:29, Scott C. Frase wrote: Thread 10 (Thread 2047089584 (LWP 6752)): #0 0x082a634c in WaveCacheItem::get_size (this=0x981d220) at wavecache.C:18 #1 0x0813fded in CacheBase::get_memory_usage (this=0x8c04068) at cachebase.C:152 #2 0x081eff7b in MWindow::age_caches (this=0xbfc5a288) at mwindow.C:1559 #3 0x081f08d3 in MWindow::update_project (this=0xbfc5a288, load_mode=3) at mwindow.C:1852 #4 0x081f301c in MWindow::load_filenames (this=0xbfc5a288, filenames=0x7a0413e8, load_mode=3, update_filename=0, reel_name=0x82eb360 none, reel_number=-1, overwrite_reel=0) at mwindow.C:1133 #5 0x081c8276 in LoadFileThread::run (this=0x8c68020) at loadfile.C:149 #6 0xb7b88bb8 in Thread::entrypoint (parameters=0x8c68020) at thread.C:48 #7 0x00da0b80 in start_thread () from /lib/libpthread.so.0 #8 0x00c11dee in clone () from /lib/libc.so.6 This is the interesting piece. Your last post also showed that a thread was working in MWindow::age_caches(). Next time, you have a hang can you please go to this thread and see which function takes so long to finish? age_caches() has 4 calls to get_memory_usage around line 1559. It's easiest if you use KDbg. Attach to the hanging process, Look up the thread in the Thread window, then use Execute-Step Into and -Step out; I suspect that one of these functions takes long to complete; you will notice it when Step Out takes a while to come back. Welcome to the Hacker's guilde! ;) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Newbie] 2 basic questions on working with Title effect on the timeline
On Saturday 03 February 2007 01:48, T.Guilleminot wrote: 2. I cannot find how to (if we can ?) resize (reduce) a duration of a title effect *without* shifting all the following. I can move forward and increase duration but on any reduction or move backward it pulls all the other effect and shift all my titles in the entire project. I checked Docs, tried to protect area with IN OUT points (...) but no chance... The only workaround I found is to drop and recreate the title which is quite annoying. Is it possible to reduce ? Use middle mouse button + Shift. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] gpl headers
On Tuesday 30 January 2007 23:40, muzzol wrote: hi again, im sad to see no developers are answering. this is really serious, in fact it could be a GPL license violation and is as simple to resolv as applying a simple patch. this is mainly focused to developers but i would like to hear oppinions here. 1. If the license text is in the root directory of the source code, it is made absolutely clear how the source code thereunder is licensed. It is in no way necessary to write a license preamble in each and every file. 2. I take licenses series. But that does not mean that I'm going to look whether any code in the cinelerra directory is violating the license. Almost all of the code was written by someone else. 3. I will not waste my time writing preambles into files. 4. Your religion (Debina+Ubuntu+FSF) does not conflict with mine (briefly outlined above). Therefore, I see no reason to reject patches if you send them in. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Audio fader,
On Tuesday 30 January 2007 10:25, Marcin Kostur wrote: Since 2.1 i audio level automation curve on timeline movable in 50%-100% of track. I remember there was some soution to this - anybody can remind me? In the status line, there are tumblers where you can change the limits. It says Audio Fade: here. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] play / stop problem
On Tuesday 30 January 2007 20:15, peter_westenberg wrote: whenever I hit the space / push the play button in both compositor and timeline, playing cannot be stopped ... any clues? Preferences, Playback, Audio. Stop playback locks up ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] svn sources not building on 64-bit Gentoo
On Friday 26 January 2007 09:58, Alexis Ballier wrote: I'd change this to : if test x$enable_mmx != xyes; then ff_conf_args=$ff_conf_args --disable-mmx fi otherwise ffmpeg's configure tries to enable mmx where it should not as on x86_64 the default value for enable_mmx is auto now. Thanks, fixed. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Simple Question: Deinterlace Raw DV footage ?
On Wednesday 24 January 2007 05:25, Nathan Kidd wrote: Robbt wrote: I used deinterlace and it seems to fix the problem. Ok, so I did the proper thing and read Wikipedia and found out the glory of mouse teeth or tearing, but I'm still wondering the specifics of this as it applies to Cinelerra. I plan on editing this video so that it can be displayed via DVD. Should I just add the Deinterlace effect to the whole video ? No, definitely you should not. DVDs are interlaced. When played on a normal TV screen you won't see any artifacts. When played on a progressive scan display like your computer monitor you will. So normally your computer dvd player will do the deinterlacing itself. You should not use the deinterlace plugin in Cinelerra or your footage will look way worse when played by a normal set top dvd player. Basically I agree with Nathan, but please keep in mind that Cinelerra is mostly interlace agnostic. If you want to do any vertical pannings or scalings, you get ugly results. Also, if you apply any animated effects or masks, interlaced material should(*) actually be rendered at double the frame rate, but Cinelerra will not do it. (*) note the 'should'; Cinelerra will still produce usable results. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: Bug when loading a DV file
On Sunday 21 January 2007 23:20, Nicolas Maufrais wrote: On Sun, Jan 21, 2007 at 09:28:52PM +0100, Johannes Sixt wrote: Try to comment out the two lines that reference 'temp_frame' in qth264.c - does that also crash? I commented out the 2 lines of qth264.c and recompiled r983 with the debugging symbols. I load the .DV file and then Cinelerra didn't crash. In fact, it freezed. The mouse cursor looks as a clock, and nothing happens. I had to Ctrl-C Cinelerra in gdb. Here's the output: http://www.europephoto.com/temp/gdb_output_r983.txt The curious thing is, that one thread (the top-most in this list) is inside FileCR2. What are you loading here? -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Patch] Reordering cpu checks to be able to enable 3dnow or altivec
On Wednesday 10 January 2007 08:38, Alexis Ballier wrote: Any news on this ? I was waiting for this to package a new snapshot and then have been quite busy :/ I've fixed this now, I think. Please test. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fix for 327 - need testers
Nicolas, thanks for trying. On Tuesday 09 January 2007 00:26, Nicolas Maufrais wrote: So, I did loaded the project with the latest revision, and older revisions (I have more than 30 revisions of cinelerra installed on my system for testing and bug reporting purpose). I tracked the bug, and it appears in r945. The project loads fine with r944 and previous releases, and crashes in r945! That's strange, because here's the SVN commit note: r945 | minmax | 2006-10-21 00:51:56 +0200 (Sat, 21 Oct 2006) | 2 lines Revert merge of editing modes Anyway, I really would like to test your patched revision with that project, because it'd really be a good test to validate the changes you made. You can easily attach the changes onto r944 in this way: # create a test branch $ git-branch fix-for-944 # attach it onto r944 $ git-rebase --onto cb60b61e8 dd3575b15e4 fix-for-944 (Use 'gitk master fix-for-944' to verify that cb60b61e8... is r973 and dd3575b15e4... is r944, and you can use other commit ids for --onto if you want to.) Here's the gdb output when opening the project in r945: http://www.europephoto.com/temp/bug_when_loading_huge_project_in_r945.txt I know this crash and have looked into it in the past, but can't reproduce it. It must be some race condition or memory corruption in some other part of the program. What codec is inside your AVI? -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Fwd: SVN Revision 978, failed to build [EMAIL PROTECTED]
On Tuesday 09 January 2007 13:44, Jean-Luc Coulon (f5ibh) wrote: (Forwarded with the correct identity, sorry) Le 09.01.2007 13:43:15, Jean-Luc Coulon (f5ibh) a écrit : Hi, guicast/vframe.h has the following include statement: #include colormodels.h But colormodels.h is not located in the guicast directory but in the quicktime directory. So the statement should be: #include ../quicktime/colormodels.h There is this in guicast/Makefile.am: INCLUDES = -I$(top_srcdir)/quicktime Hence, the extra path parts in #include are not necessary, and I don't see why the current state would fail to compile. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] svn rev973: ./configure neglects xorg, tiff
On Wednesday 27 December 2006 23:56, Joe Friedrichsen wrote: I installed debian etch yesterday and decided to compile cinelerra from svn. Since the install was minimalistic, I used ./configure to help me find the (numerous) missing development libraries. After the final summary told me that all were found, compilation broke a few times because ./configure missed a few. Missing packages that weren't reported as missing: libxxf86vm-dev -- X11/extentions/xf86vmode.h libxv-dev -- X11/extensions/Xvlib.h libtiff4-dev -- tiffio.h Are these the dependencies alluded to on http://cvs.cinelerra.org/svnusage.php: Most of the missing dependencies should be listed after running ./configure, (and the rest can be somewhat worked out from the compile error message you get.)? In other words, is this build process expected? Yes ;) I don't feel like adding reports about missing X11 devel libraries. libtiff otoh is probably not too commonly installed and should be reported... -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] AUTHORS file in svn
On Wednesday 27 December 2006 16:38, Christian Thaeter wrote: my svn-git sync broke recently because of a unknown author (welcome rafael2k :P), no big problen and easy to fix but anyways: How about maintaining the AUTHORS files instead leaving it empty? currently I have http://www.pipapo.org/.cinelerra-svn_sync/authors I would just suggest to check that into the svn as AUTHORS. Then I can remove the lowercase version and whenever a new auhtor appears someone (maybe me, in the git tree, since I will notice when it breaks) would care about new commiters. May someone with svn access do this? then i'll update my script. I'm not sure that this is the best thing to do. The authors file that you need can only list the authors with svn access and must conform to a very strict syntax, but OTOH there is at least also HV to be mentioned in AUTHORS plus possibly a lot of other people who have contributed patches. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Memory desert
On Sunday 24 December 2006 14:59, Miha Kitič wrote: While comparing the latest SVN to r827 I noticed another interesting feature - that is, the latest SVN likes memory a lot. I loaded an MPEG clip and rendered it a couple of times (same settings, same clip, same everything). Each rendering occupied more and more memory. After rendering it a couple of times the entire memory of my computer was used up (mem + swap = 1GB). Soon after that Cinelerra either crashed or the rendering got stuck. When I tried the same thing on r827, this didn't happen. Cinelerra occupied app. 150Mb of memory and it didn't take more no matter how many times I rendered. Please try the modification proposed in this message: https://init.linpro.no/pipermail/skolelinux.no/cinelerra/2006-November/008696.html whether it improves the situation. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Annoyance: changing media type changes file name
On Sunday 24 December 2006 18:35, Andraž Tori wrote: On Thu, 2006-12-21 at 22:48 +0100, Johannes Sixt wrote: I find it most annoying that changing the media type also switches the file name, in particular, because when you work through the dialog top to bottom, the first thing to choose is the file name, then comes the media - but when you change it, it kills the file name that you have just selected. I'd like to kill the feature. Nate? You've added this 2 years ago. Has someone else been annoyed by this behavior? Has someone found this feature extremely useful? It would be extremely useful if just the extension would change, but not the full filename. I've commited a patch series that implements this behavior. Actually, HV has added it for 2.1, but it was hidden by our own modifications. Some of Nate's changes are still present. Most notably, the recent files list are still per format, which I think is a useful feature. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Dissolve transition to transparent PNG image
On Thursday 21 December 2006 06:30, Joey Richards wrote: Hello, I'm having trouble with dissolves into static PNG images. I have a simple video with two tracks -- one for the video and another where I place PNG title images, etc. These titles are text on a translucent (alpha1) background rectangle to increase readability. I'd like these to quickly fade in and out to avoid the jarring affect of their suddenly popping on to the screen. I tried this with a dissolve transition at the start and end of each region with the PNG image. The title track is empty between PNG images. The dissolve from an image to a blank region works as I expect -- the background box gently fades out. The transition when the PNG appears does not work correctly. On the first frame as the dissolve begins, a very dark region corresponding to the text background box appears and then the image fades in. This is what I'd expect if the alpha is not being correctly interpolated -- e.g., if it faded from 1 instead of from 0. In case this was a problem with a transition from nothing to the image, I have tried placing a blank (alpha = 0 everywhere) image before the PNG title -- no effect, it still pops in black then fades in. I can get the effect I want by keyframing the fade attribute of the track, but this is a lot more tedious than just dropping a dissolve onto the clip. Please create a bug report, bugs.cinelerra.org. Attach a small project that shows the problem, along with the PNG (video is not needed). -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Bug 364
On Saturday 23 December 2006 09:14, Miha Kitič wrote: If you decide to build 2.0, it looks to me like r836 is the last svn version prior to the start of the merge. Thank you for your advice. I may try this. But I never DL any other except the last SVN. How do you DL r836 (which addres should I use)? Would for instance the: svn checkout svn://svn.skolelinux.org/cinelerra/tags/r8_3_6-last/hvirtual Do the trick? Not at all, sorry. In a checked-out copy do this: svn update -r836 To get a clean checkout to this: svn checkout -r836 ...repo-url-like-normally... -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Annoyance: changing media type changes file name
In the Render dialogs the media type (.mov, .avi, RAW DV etc) can of course be changed. Cinelerra CV remembers a different file name for each media format. I find it most annoying that changing the media type also switches the file name, in particular, because when you work through the dialog top to bottom, the first thing to choose is the file name, then comes the media - but when you change it, it kills the file name that you have just selected. I'd like to kill the feature. Nate? You've added this 2 years ago. Has someone else been annoyed by this behavior? Has someone found this feature extremely useful? -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Exporting to mpeg video..
On Tuesday 19 December 2006 13:20, Pierre Marc Dumuid wrote: I was just writing a patch to save a mpeg2enc binary location. I was going to make the location settable in the Render-Video Settings window, but realised that that dialog, and the code surrounding it seems to only handle modification to the asset, and I didn't really want the binary location to vary between assets for different projects. I'm guessing that it should go in preferences dialog, but non of the tabs make sence, (it's not a recording or playback option) Any one have an idea were it should go, or if it is a good idea. Not in the Preferences, please. Let configure find it, but use the plain 'mpeg2enc' (without path, i.e. using $PATH) as a fallback. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Concerning error message on compile
On Monday 18 December 2006 01:47, [EMAIL PROTECTED] wrote: echo 0x7 fff /proc/sys/kernel/shmmax Remove that blank between 7 and f. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Creating DVD from Cinelerra: input source
On Saturday 16 December 2006 21:41, Yannick Patois wrote: Hi, If I understand, PAL DVD format have 25f/s images, 720x576 pixels, and 4:3 aspect ratio. But I also read that those are non square pixels (they must be because 720/576 != 4/3), and that point is worrying me. As I'm creating my movie from images, what would be the best for me? Should I keep rendering 640x480 images (4:3 aspect ratio) images with square pixels and let cinelerra work from it? Should I render 720x576 images with non square pixels? I'll assume that you create you images with square pixels. Then the simplest approach that gets you closest to the expected result is to create 768x576 images and scale them to 720x576. (Cinelerra can do this for you, but I didn't find a straight-forward way to do it, so you may want to automate this outside Cinelerra). But this is just half the truth. Because a PAL frame's area that is to be mapped onto a 4:3 screen is actually taken from a 704x576 sub-area of the available 720x576. Hence, if you need absolutely correct aspect ratio, you better scale the 768x576 images to 704x576, and then add a black border of 8 pixels to the left and right to get the 720x576. But I doubt that you will notice a difference on a TV. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] bug in mask editing
On Tuesday 12 December 2006 18:01, IL'dar AKHmetgaleev wrote: when I undo a vector mask editing cinelerra goes down Even when no video footage loaded in project I cannot reproduce this. Please fire up cinelerra in gdb and post the result of 'thread apply all bt' -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] [Bug 347] Crash on with title and reverb effects
On Monday 04 December 2006 19:52, m h wrote: Bumping this bug... 1 month and no replies. I take it either no one is interested in reverb, or this isn't happening for others (or people are just ignoring my posts I hope this one is not the case). I tired it one month ago, and I tried again now. It just does not crash here. If you see the crash if you have only a simple WAV file plus the reverb effect, then please post a minimal project file that crashes. (don't attach the WAV file - everyone, including me, has lots of WAV files to plug in. ;)) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] New klocwork results...
On Monday 04 December 2006 19:54, m h wrote: Not sure if anyone is interested but the kind people at klocwork have recently re-ran their tool against the post 2.1 merged code base. If people are interested in the results, let me know. Sure are we interested. Please sift through the results and post what you think is a serious bug. You can address me personally, if you like (but please just don't let me drown in reports ;) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] about localization mantainers
On Monday 27 November 2006 23:38, Nicolas Maufrais wrote: Since you seem to know how to run Cinelerra in another language than English, could you please explain me how you do? It's written here: http://cvs.cinelerra.org/docs/split_manual/cinelerra_cv_manual_3.html#SEC22 However, that never worked for me... $ export LANG=fr_FR $ echo $LANG fr_FR $ ./cinelerra - cinelerra in... English... :-/ I think the files containing the translated strings aren't installed when typing make install. Is there any manual action needed? You have to install in /usr, i.e. ./configure --prefix=/usr otherwise the language files will not be found. If don't want this, you can install just the language files in /usr like this: $ ./configure prefix=/usr $ cd po $ sudo make install $ cd .. $ ./configure # as usual, implies prefix=/usr/local -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] about localization mantainers
On Tuesday 28 November 2006 21:06, Nicolas Maufrais wrote: Is it normal that po files aren't installed in the specified prefix? Isn't that a bug? They _are_ installed in the prefix that you specify in ./configure, but the path where they are looked up seems to be hardcoded in main.C as if the prefix were /usr. I'd say this _is_ a bug. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra CV Manual available
On Friday 17 November 2006 01:57, Timothy White wrote: On 11/17/06, Nicolas [EMAIL PROTECTED] wrote: Hello, For those interested in having a look at the new Cinelerra CV manual, you can fetch it using the following command: cg-clone git://scm.pipapo.org/cinelerra-nicolasm $ cg-clone git://scm.pipapo.org/cinelerra-nicolasm defaulting to local storage area Fetching pack (head and objects)... warning: no common commits fatal: early EOF fatal: git-unpack-objects died with error code 128 cg-fetch: fetching pack failed cg-clone: fetch failed Any ideas what's wrong? cg-clone creates a new local repository. Be sure that you don't have set up one (with cg-init or git-init-db) and cd'd into it! -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra gives symbol undefined error after compilation
On Monday 06 November 2006 00:08, robbt wrote: Hi everybody. I just tried to compile Cinelerra for my machine since the debian package wasn't rendering correctly. Now I'm getting this symbol undefined error. cinelerra: symbol lookup error: cinelerra: undefined symbol: _ZN13BC_WindowBase12create_xatomEPc I was getting a similar error when I tried to compile Cinelerra before. Is there any solution or way to fix it or should I just file it as a bug report and figure I can't use Cinelerra until it gets figured out. You have an old libguicast that is picked up. Remove it. Investigate the output of ldd /usr/local/bin/cinelerra to find out where the wrong libguicast is. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] What happened to those effects: Linearize, Reframe and Resample?
On Sunday 05 November 2006 00:56, Nicolas wrote: Hello, While working on the manual, I noticed there are paragraphs about the following effects in Secrets of Cinelerra (v2.1): - Linearize This one *is* present in my version. - Reframe - Resample These are not real-time effects. They are only available in Audio-Render effect and Video-Render effect. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] merge editing modes
On Thursday 19 October 2006 19:11, Andraž Tori wrote: a patch that completely merges both editing modes of cinelerra into a single one, with shift key being the modifier ... editing modes are one of the hardest things for new learners of cinelerra to comprehend (by my experience) and there is really no reason not to merge them, since most of people expect to use shift for selecting. bye andraz Andraz, please revert this change. While it may get newbies going faster, it makes at least my workflow completely awkward, because I never use dragdrop mode. I would always have to have the Shift key down. And even then I cannot place the cursor precisely on the start or beginning of a media or effect border because it just extends the existing selection (clicking in the time bar is not precise enough). Now, what would you think about switching to git? Then you could easily publish such a change for others to test without forcing all users to use it right away. (Well, a svn branch could also be used...) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] merge editing modes
On Friday 20 October 2006 20:49, Andraž Tori wrote: Yes, since everyone is so overhelmingly against this change, i'll find out some other solution ... Though i still think editing modes are something that confuses users... it's the same as emacs ... powerful but only handfull of people will master them. i'll try to code up something tomorrow Please, pretty please, make the reversal of r942 a *separate* commit, not intermingled with whatever your new solution will be. Thank you, -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Compile Errors Out On Playback3d.o
On Tuesday 10 October 2006 18:20, Aaron Newcomb wrote: Hey everyone. I am trying to compile the latest SVN version with ... ./configure --enable-opengl --enable-mmx --enable-3dnow --with-bluedottheme but make errors out with the following ... playback3d.o: In function `Playback3D::do_fade_sync(Playback3DCommand*)': /tmp/hvirtual/cinelerra/playback3d.C:1429: undefined reference to `glUseProgram' You must have OpenGL 2.0 capable libraries, which means Nvidia's closed drivers. If you don't have them, don't use --enable-opengl. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] audio levels
On Sunday 01 October 2006 18:17, Herman Robak wrote: On Sun, 01 Oct 2006 17:20:26 +0200, Raffaella Traniello [EMAIL PROTECTED] wrote: Fading and amplification are typically separate knobs or levers: the amplification setting is usually called gain. Cinelerra has a gain effect that you can attach to audio tracks. I've tried it. It starts at 0 and can gain up to 40. Since there are also negative values, it can fade down to -40. Since the fader goes above the unity level and the gainer goes under it, they don't appare so separated to me. Why is better to keep them independent? Good question. An audio professional could explain why this makes perfect sense. My explanation may be a little naive and inaccurate... While i'm neither audio expert nor electronic guru, i do expect an amplifier and a fader to have quite different analog electronic circuitry. It just happens so that both operations on digital audio are the same operation - multiplication - and can be achieved by the same knob. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] audio levels
On Saturday 30 September 2006 17:45, Pierre Marc Dumuid wrote: Prior to discussions with j6t on IRC, I had been considering setting the INFINITYGAIN as a property of the current project (thus 24 bit audio freaks could specify huge attenuations). j6t advised against this (micromanagement), but on considering the problem of old projects issues, I wish for this to be re-considered. What do people think? I personally see the idea of having a per-project minimum dB as good, both for backward compatibilty, as well as for professionals.. I was going to also make the default for new projects independent of the last project, (i.e. the default for a new project would always be -96 dB.) I still don't see a necessity for a _user settable_ option. I now propose to indeed make this INFINITYGAIN a project option, -96dB by default (or even -144dB to account for 24bit audio) for _new_ projects. But: - write the setting into a property; - read the property in with -40dB if it is not present in the file. (place sufficient commentary into this code, please, to document the design decisions ;) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Title Motion Effects?
On Monday 25 September 2006 10:55, Timothy White wrote: On 9/23/06, Miha Kitič [EMAIL PROTECTED] wrote: OK, that's great news! I can now set exact values for controls in the timeline. I didn't know that was possible. snip On pet, 2006-09-22 at 20:15 +0200, Johannes Sixt wrote: snip There is a button Show tool info on the Compositor. Use it. For some reason it doesn't work for me. No window appears. Just updating to latest SVN as well You have to turn on Adjust camera automation in the Compositor, too. Also, moving the Camera position doesn't appear to effect things like the title effect. Keyframing the title plugin, doesn appear to give a fluid motion, it jumps from one setting to another. Maybe I'm missing something here :( The Title plugin does not interpolate any of the settings. :( -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] SVN 899, windows are no more placed
On Monday 25 September 2006 15:08, Jean-Luc Coulon (f5ibh) wrote: Hi, With this SVN version, the windows are no more placed as they was in the past. - When I launch cinelerra, some are stacked, the ressources window is correctly placed. - If I use Window -- Défault Positions, I get the default positions as before but the size is slighly less than the screen. In fact, there is a border around each window. - The placement is not saved between sessions. I had not this behaviour with previous versions. I cannot reproduce this with r901. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Concatenating projects and keeping labels positions
On Sunday 24 September 2006 18:11, Nicolas wrote: Is there a simple way to concatenate several projects into a large project, while keeping the labels at their right place? Assumeing all projects have the same track layout (number of video and audio tracks): 1. Fire up each project in its own cinelerra instance 2. Make sure in each one the following is on: - Settings-Edit labels - Cut paste editing mode (the I-beam button in the toolbar) - Arm all tracks in all projects. 3. Kill Klipper if your build is not up to date. 4. Repeat for projects 2 to n: - Select wanted region - Edit-Copy (or 'c') - Select insertion point in Project 1 - Edit-Paste (or 'v') -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Title Motion Effects?
On Friday 22 September 2006 11:23, Bernhard Frühmesser wrote: Miha Kitič wrote: I am not sure I will give you a useful answer, but let me try :) Yep, thanks. Well getting the lines for camera x y and z wasn´t or isn´t the problem, also changing the values on the timeline isn´t the problem, but i don´t get the Camera Tool Window where you can set values more detailed than on the timeline. Should this window open automatically when camera x y or z is shown? There is a button Show tool info on the Compositor. Use it. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: Ubuntu AMD64
On Tuesday 19 September 2006 16:31, Timothy White wrote: it starts to load, I even see the Splash screen, and then it gets to initialising GUI and it all disappears, and I get: MWindow::init_theme: theme SUV not found. This is because you used --disable-shared --enable-static. This option combination doesn't build any plugins. Don't use either of them. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cin 2.1 lockup on re-load
On Friday 15 September 2006 11:59, Andraž Tori wrote: On Thu, 2006-09-14 at 21:35 +0200, Johannes Sixt wrote: On Thursday 14 September 2006 03:50, Kevin Brosius wrote: restart cin use the quick reload items to reload your project the main cin window is hung, with the hourglass. Pressing ctrl-c in the xterm to kill cin. I've observed this, too, and tried to debug it. I just can't get a grip of it... There are numerous deadlock conditions between main window and asset window. But the only possible way for fixing all of them is for cinelerra to use ansynchronous function calls between window threads instead of direct calls. I have no proof that the lockups on loading are not of this nature, but I have some evidence that it is something different, maybe X11 related. One of the threads hangs in XShmAttach (via MainClock::update() and a BC_Bitmap constructor), waiting for an _XReply. A different one waits inside VDeviceX11::open(). And note haw a BC_Repeater is in XLockDisplay() of the same window. Find attached the only suspicious threads. Any hints are welcome. -- Hannes Thread 20 (Thread 1233201472 (LWP 5185)): #0 0x2b0a252717f6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2b0a22cbff65 in XInitThreads () from /usr/X11R6/lib64/libX11.so.6 #2 0x2b0a22cc0067 in XLockDisplay () from /usr/X11R6/lib64/libX11.so.6 #3 0x2b0a227f98d8 in BC_WindowBase::lock_window (this=0x126dcf0, location=0x2b0a22814ee3 BC_Repeater::run) at ../../../cinelerra-svn/guicast/bcwindowbase.C:2610 #4 0x2b0a227d8498 in BC_Repeater::run (this=0xb09860) at ../../../cinelerra-svn/guicast/bcrepeater.C:111 #5 0x2b0a2280edb6 in Thread::entrypoint (parameters=value optimized out) at ../../../cinelerra-svn/guicast/thread.C:48 #6 0x2b0a2526e193 in start_thread () from /lib64/libpthread.so.0 #7 0x2b0a2559247d in clone () from /lib64/libc.so.6 #8 0x in ?? () Thread 31 (Thread 1149274432 (LWP 5174)): #0 0x2b0a252717f6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2b0a22cc00d0 in XLockDisplay () from /usr/X11R6/lib64/libX11.so.6 #2 0x2b0a227f98d8 in BC_WindowBase::lock_window (this=0x126dcf0, location=0x7b8bfb VDeviceX11::open_output) at ../../../cinelerra-svn/guicast/bcwindowbase.C:2610 #3 0x2b0a227f989a in BC_WindowBase::lock_window (this=0x12d3f80, location=0x7b8bfb VDeviceX11::open_output) at ../../../cinelerra-svn/guicast/bcwindowbase.C:2604 #4 0x00724685 in VDeviceX11::open_output (this=0x15772c0) at ../../../cinelerra-svn/cinelerra/vdevicex11.C:73 #5 0x00725e74 in VideoDevice::open_output (this=0x1571660, config=0x1685ef0, rate=25, out_w=512, out_h=384, output=0x12d0530, single_frame=1) at ../../../cinelerra-svn/cinelerra/videodevice.C:662 #6 0x006d6960 in RenderEngine::open_output (this=0x16ae0a0) at ../../../cinelerra-svn/cinelerra/renderengine.C:328 #7 0x006d6d2c in RenderEngine::arm_command (this=0x16ae0a0, command=0x12dd670, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../../../cinelerra-svn/cinelerra/renderengine.C:158 #8 0x0068dc23 in PlaybackEngine::arm_render_engine (this=0x12db900) at ../../../cinelerra-svn/cinelerra/playbackengine.C:126 #9 0x0068dd8a in PlaybackEngine::run (this=0x12db900) at ../../../cinelerra-svn/cinelerra/playbackengine.C:389 #10 0x2b0a2280edb6 in Thread::entrypoint (parameters=value optimized out) at ../../../cinelerra-svn/guicast/thread.C:48 #11 0x2b0a2526e193 in start_thread () from /lib64/libpthread.so.0 #12 0x2b0a2559247d in clone () from /lib64/libc.so.6 #13 0x in ?? () Thread 11 (Thread 1308735808 (LWP 5194)): #0 0x2b0a252717f6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2b0a22ca4dd3 in _XReply () from /usr/X11R6/lib64/libX11.so.6 #2 0x2b0a22c9a222 in XQueryExtension () from /usr/X11R6/lib64/libX11.so.6 #3 0x2b0a22c907d4 in XInitExtension () from /usr/X11R6/lib64/libX11.so.6 #4 0x2b0a22b577ce in XextAddDisplay () from /usr/X11R6/lib64/libXext.so.6 #5 0x2b0a22b5a75e in XShmAttach () from /usr/X11R6/lib64/libXext.so.6 #6 0x2b0a227a98b7 in BC_Bitmap::allocate_data (this=0x1658ef0) at ../../../cinelerra-svn/guicast/bcbitmap.C:237 #7 0x2b0a227a9cae in BC_Bitmap::initialize (this=0x1658ef0, parent_window=0x12d2780, w=11, h=16, color_model=3, use_shm=1) at ../../../cinelerra-svn/guicast/bcbitmap.C:93 #8 0x2b0a227a9da4 in BC_Bitmap (this=0x1658ef0, parent_window=0x12d2780, w=11, h=16, color_model=3, use_shm=1) at ../../../cinelerra-svn/guicast/bcbitmap.C:55 #9 0x2b0a22803374 in BC_WindowBase::draw_vframe (this=0x12d2780, frame=0xac1550, dest_x=0, dest_y=0, dest_w=11, dest_h=16, src_x=0, src_y=0, src_w=11, src_h=16, pixmap=0x0) at ../../../cinelerra-svn/guicast/bcwindowdraw.C:870
Re: [CinCVS] Cin 2.1 lockup on re-load
On Thursday 14 September 2006 21:35, Johannes Sixt wrote: On Thursday 14 September 2006 03:50, Kevin Brosius wrote: restart cin use the quick reload items to reload your project the main cin window is hung, with the hourglass. Pressing ctrl-c in the xterm to kill cin. I've observed this, too, and tried to debug it. I just can't get a grip of it... I have a project that reliable locks up when i want to load it. Now, when I load the project as root once (sux root -c cinelerra), then i can later also load it reliably (it seems) as ordinary user... This is so weird... It's tracked in bug 282, btw. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] OpenGL support question
On Tuesday 12 September 2006 18:03, Nicolas wrote: On Tue, Sep 12, 2006 at 09:56:10AM +0200, Sylvain Jousse wrote: http://de.wikipedia.org/wiki/Geforce#GeForce_FX_series My graphics card (nvidia6600) supports opengl 1.5 but cinelerra compiles And it is said that the whole 6 serie is 'openGL 2.0 capable'. Sylvain. I'm not quite sure that wikipedia page is correct. My Nvidia 5900XT is supposed to support OpenGL 1.5 on the wikipedia page. But the information given by glxinfo is different : # glxinfo | grep OpenGL version OpenGL version string: 2.0.2 NVIDIA 87.74 This probably means that some OpenGL 2.0 features will be done by the CPU rather than the GPU. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] compile error in bcsynchronous.C: 'glDeleteShader' was not declared in this scope
On Tuesday 12 September 2006 01:30, [EMAIL PROTECTED] wrote: Guys, With the --enable-opengl switch on, I get this compile error: bcsynchronous.C: In member function 'void BC_Synchronous::delete_window_sync(BC_SynchronousCommand*)': bcsynchronous.C:408: error: 'glDeleteShader' was not declared in this scope Join in on IRC at #cinelerra to debug this. I (j6t) will be there in 11 hours from now. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] OpenGL support question
On Sunday 10 September 2006 06:33, harm Lubbers wrote: Graham Evans wrote: Chances are your card is OpenGL 1.5 not Open GL 2.0. How Do I find out that my card is only OpenGL1.5? http://de.wikipedia.org/wiki/Geforce#GeForce_FX_series The OpenGL version string in glxinfo is the first hint. If it tells you that it's 2.0, then the 2.0 features either won't work (and you'll notice this immediately) or will be emulated in software (and you'll notice it only in the rendering speed). -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Live video: how does it work?
On Saturday 09 September 2006 23:44, Bas Alphenaar wrote: Hello, I compiled r872 today and decided to give the live video plugin a go. First I switched on my Sony HDR-HC1, connected to the PC with a Firewire cable. Then I started Cinelerra with sudo cinelerra because a normal user doesn't have enough rights to use /dev/raw1394. In the Recording tab in Preferences I set everything according to PAL, the Record Driver to DV 1394 and the Device Path to /dev/raw1394. After everything was set up I added the Live Video plugin to the video track but when I played this track, Cinelerra crashed and left this in the console: Device1394Input::open DV1394_IOC_INIT: Invalid argument Device1394Input::open DV1394_START_RECEIVE: Invalid argument Device1394Input::run DV1394_IOC_WAIT_FRAMES: Invalid argument Device1394Input::open DV1394_IOC_INIT: Invalid argument Device1394Input::open DV1394_START_RECEIVE: Invalid argument Device1394Input::run DV1394_IOC_WAIT_FRAMES: Invalid argument Try /dev/dv1394 instead of /dev/raw1394 -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] OpenGL support question
On Sunday 10 September 2006 06:32, harm Lubbers wrote: OpenGL version string: 1.2 (2.0.2 NVIDIA 87.62) I'd interpret this as OpenGL 1.2, not 2.0 visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x2c 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2d 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x2e 32 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 Ncon 0x2f 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon ^^^ Cinelerra request a visual with an accumlation buffer, but there is no such visual in this list. :( -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] OpenGL support question
On Sunday 10 September 2006 15:54, [EMAIL PROTECTED] wrote: Hannes, From the output of glxinfo, it looks like my ATI 9800 Pro AIW card doesn't support 2.0 (1.2 in the output below). This does mean that I CANNOT take advantage of the OpenGL enhancements, correct? [EMAIL PROTECTED] 20060831]# glxinfo name of display: :0.0 Xlib: extension XFree86-DRI missing on display :0.0. display: :0 screen: 0 direct rendering: No ... OpenGL version string: 1.2 (1.5 Mesa 6.2.1) You don't have hardware acceleration at all. To use hardware acceleration with the fglrx driver, you have to invoke LD_LIBRARY_PATH=/usr/lib/fglrx/lib glxinfo LD_LIBRARY_PATH=/usr/lib/fglrx/lib cinelerra I'm not sure if a 9800 is capable enough to fully support OpenGL 2.0. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] OpenGL support question
On Saturday 09 September 2006 11:29, harm Lubbers wrote: Hello everybody, I am trying to get Cinelerra compiled with openGL support. I have an Nvidia FX5700 card with the nvidia drivers working. I can compile Cinelerra with the --enabel-opengl option succesfully. But when I run the program, select the openGL video output, try to play some footage, the compositorwindow doesn't show anything at all. Cinelerra reports the following error: BC_PBuffer::new_pbuffer: glXChooseFBConfig failed BC_PBuffer::new_pbuffer: glXChooseFBConfig failed Post the output of glxinfo. The interesting part is the table at the end. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra v2.1 has been Released
On Sunday 27 August 2006 20:18, Johannes Sixt wrote: We've completed the merge. Expect a substantial number of svn commits soon. The merge is not complete, yet, but almost. You might be interested to try out OpenGL support, which I've committed to svn a minute ago. You need the patches that I attach here to enable it. One of them will find its way into svn later. * If you have complete OpenGL 2.0 support (currently only available from NVidia), apply only opengl-configure.diff. * If you don't have complete OpenGL 2.0 support (e.g. MESA software rendering), you can add both patches. But this will cripple most OpenGL-enabled effects; they don't produce output or whatever. But at least the Dissolve transition will work. Apply the patches with patch -p1 xxx.diff. Run ./configure --enable-opengl You have to choose X11-GL in the Preferences to enable OpenGL. Also read the new manual about additional constraints (basically, don't mix hardware and software effects). Don't report bugs. Wait until the merge is complete. You can meet me at #cinelerra on IRC in 9 hours from now if you need help. -- Hannes commit 8dc6f09832dcf1ef2732c6121cc7ba0055e5cd29 Author: Johannes Sixt [EMAIL PROTECTED] Date: Mon Aug 21 22:46:06 2006 +0200 This makes OpenGL build. diff --git a/guicast/bcpbuffer.C b/guicast/bcpbuffer.C index 28c955b..03830d4 100644 --- a/guicast/bcpbuffer.C +++ b/guicast/bcpbuffer.C @@ -78,9 +78,9 @@ #define TOTAL_CONFIGS 1 GLX_ACCUM_GREEN_SIZE, 1, GLX_ACCUM_BLUE_SIZE, 1, GLX_ACCUM_ALPHA_SIZE, 1, - GLX_RED_SIZE, 8, - GLX_GREEN_SIZE, 8, - GLX_BLUE_SIZE, 8, + GLX_RED_SIZE, 5, + GLX_GREEN_SIZE, 5, + GLX_BLUE_SIZE, 5, GLX_ALPHA_SIZE, 8, None }; diff --git a/guicast/bcwindowbase.h b/guicast/bcwindowbase.h index eeecf27..c438574 100644 --- a/guicast/bcwindowbase.h +++ b/guicast/bcwindowbase.h @@ -74,6 +74,25 @@ #include X11/extensions/xf86vmode.h #endif #ifdef HAVE_GL #include GL/glx.h +#define glAttachShader(...) 0 +#define glCompileShader(...) 0 +#define glCreateProgram(...) 0 +#define glCreateShader(...) 0 +#define glDeleteShader(...) 0 +#define glGetProgramInfoLog(...) 0 +#define glGetShaderInfoLog(...) 0 +#define glGetUniformLocation(...) 0 +#define glLinkProgram(...) 0 +#define glShaderSource(...) 0 +#define glUniform1f(...) 0 +#define glUniform1i(...) 0 +#define glUniform2f(...) 0 +#define glUniform2fv(...) 0 +#define glUniform3f(...) 0 +#define glUniform4f(...) 0 +#define glUniform4fv(...) 0 +#define glUniformMatrix3fv(...) 0 +#define glUseProgram(...) 0 #endif commit aac9716cad561d0a4746e7d98dbdfee883668298 Author: Johannes Sixt [EMAIL PROTECTED] Date: Thu Aug 31 22:40:43 2006 +0200 Provide a configure option to turn on OpenGL support. diff --git a/configure.in b/configure.in index 3a1a425..229755e 100644 --- a/configure.in +++ b/configure.in @@ -326,6 +326,18 @@ AC_CHECK_HEADER(lame/lame.h,[libmp3lameh AC_CHECK_LIB(mp3lame,lame_init,[libmp3lame=yes],,[$XIPH_LIBS]) # END LAME +## OpenGL +AH_TEMPLATE(HAVE_GL, [Define to 1 if OpenGL 2.0 is available.]) +AC_ARG_ENABLE(opengl, + AC_HELP_STRING([--enable-opengl], + [enables hardware accelerated rendering (requires OpenGL 2.0)]), + if test x$enableval = x; then + AC_DEFINE(HAVE_GL) + OPENGL_LIBS=-lGLU -lGL + fi, [:]) +AC_SUBST(OPENGL_LIBS) +# END OpenGL + ## .png TO .o CONVERSION AC_CHECK_TOOL(OBJCOPY, objcopy) diff --git a/guicast/Makefile.am b/guicast/Makefile.am index eff8704..0757701 100644 --- a/guicast/Makefile.am +++ b/guicast/Makefile.am @@ -1,7 +1,7 @@ lib_LTLIBRARIES = libguicast.la noinst_PROGRAMS=bootstrap -libguicast_la_LIBADD = -lXxf86vm -lXv -lXext -lX11 $(X_EXTRA_LIBS) +libguicast_la_LIBADD = $(OPENGL_LIBS) -lXxf86vm -lXv -lXext -lX11 $(X_EXTRA_LIBS) libguicast_la_LDFLAGS = $(X_LIBS) -version-info 1:0:0 libguicast_la_SOURCES = \ bcbar.C \
Re: [CinCVS] Bezier automation
2.1 has a menu entry Straighten keyframes. I haven't played with it yet, but from the naming I'd conclude that it is a workaround that allows to have straight line segments instead of bezier interpolation between keyframes. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: libx264 fix WORKED! was Re: newbie here, was Re: [CinCVS] Will not compile - Open SUSE 10.1
On Sunday 27 August 2006 23:28, Yama Ploskonka wrote: ln -s libx264.so.46 libx264.so.45 This apparently (?) makes Cinelerra believe you have libx264.so.45 while it actually uses libx264.so.46. This will likely crash cinelerra, _if_ you use h264 encoding. It still has that runaway thing that when I start play, sometimes it will not want to stop and will become completely unresponsive. Any fix for that? Go to Settings-Preferences-Playback; if you have choosen the ALSA audio driver, then enable Stop playback locks up. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra v2.1 has been Released
We've completed the merge. Expect a substantial number of svn commits soon. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Initial klocwork report
Thanks, Matt, for getting this going. Please send patches. On Wednesday 23 August 2006 17:54, m h wrote: -493 Null pointer dereference defects: 1. most of these resulted from the code using an allocation function like malloc and then dereferencing the result without checking. We know that everybody using cinlerra has enough memory, so malloc cannot return NULL ;) This is uninteresting for the moment. But if you find easily fixable instances, then lets better be safe than sorry. 2. a significant amount also came from the tool noticing that the results of functions like 'Vframe::get_rows', Record::get_current_batch', and 'Record::get_editing_batch' can technically be null and are often dereferenced without checking. I don't know about this. Andraz, do you have some info on these? 3. If you wish, we are able to tune the tool, forcing it to ignore the possible null returns of functions like the three mentioned above. -160 Memory Management defects: 1. A significant number of these defects resulted from the tool being triggered by the 'SHOW_GUI_MACRO'. In principle, not interesting; but if there are code paths that can be hit many times (i.e. leaking many small objects), this becomes interesting. -107 Unintialized Data 1. To our eyes, these defects are correct. However, I have a suspicion that for certain of these defects the code structure ensures the conditions for uninitialized data will not be met. Someone familiar with the cinelerra code would have to confirm this. From our point of view though, one can never be too careful. Usually, these are interesting cases. -254 Security Vulnerabilities 1. Most of these are 'array out of bounds violations'. Like the uninitialized data defects, someone familiar with the code may say that most of these defect conditions will not occur. However, from our point of view, a system may be compromised by malicious function calls, or any other such unaccounted for program behaviour. Array out of bounds are very interesting bugs, _unless_ an array[BCTEXTLEN} is involved. (Many of such uses construct filenames; here we assume that the user is well-behaved and does not have hell-deep directory hierarchies.) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Moving camera keyframes to the right
On Saturday 19 August 2006 10:48, Nicolas wrote: I really don't understand... In the past, I already tried to copy/paste keyframes, and it did not work. On yesterday evening, following your advice, I tried again. It perfectly worked. I tried Shift-C, Shift-V, and Copy Keyframes Paste Keyframes in the menu. All of these actions worked perfectly. On today, I try again, and it's impossible to copy/paste any keyframe anymore! The explanation is that you are using KDE and have Klipper running. Quit it! (In case you don't know, it's one of the taskbar icons). -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Horizontal Scroll Bar Problems
On Friday 18 August 2006 19:25, James Colannino wrote: Herman Robak wrote: Could you upload a screenshot somewhere? http://james.colannino.org/downloads/mailinglists/snapshot6.jpg James Your problem is that the horizontal zoom is at 0:00:00. See the drop-down widget at the lower left. change it. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: More suggestions from [l]users who don't contribute..
On Wednesday 16 August 2006 22:19, m h wrote: Should do I have the support of maintainers to proceed with klockwork, given that I only fix (submit patches) the interesting bugs? By all means, yes. I take it that you are the interface to klocwork and do the filtering of the reports. We can brief you about the definition of interesting, although this may be worked out when the patches start flowing in. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] select objects in tracks?
On Thursday 17 August 2006 18:08, mack wrote: can I bring 'just the video' from a clip containing audio and video tracks? without rendering into a video only clip and getting the video from there? Disarm all audio tracks. To arm a single (e.g video) track, just hit Shift-Tab while the mouse is over the track. Then paste or drag the media to the timeline. Observe and/or change the arm state by the Record button in the patch bay (left of the tracks). what i'm really trying to figure out is how to have a single audio clip rolling, while changing the video repeatedly (interviewee/some stock/back to interviewee). Just place the two video tracks above each other. Turn on Generate keyframes while tweaking (a toolbar button). Turn on Mute keyframes. Mute the upper track to have the lower track displayed. You do this by clicking the blue Mute line (*) and dragging the handle up. (*) You want to turn off Camera and Projector automations (View menu) because some of them are also blue. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: More suggestions from [l]users who don't contribute..
On Wednesday 16 August 2006 20:07, m h wrote: Ok, so in the meantime I used 2.0 for a little bit more and (got so frustrated with silly crashes that I) pulled out valgrind. Amazingly there were cases where it didn't crash when running under valgrind, that would immediatley crash otherwise. So I'm volunteering myself to work with these scanning companies if they accept (in fact I've already sent them proposals). I'm haven't done C++ in years (mostly using python and java), but I think this will be a worthwhile way to improve the stability of cinelerra. What I need from the core maintainers is help and advice. I already recieved a response from klockwork. They want to know if I'm a maintainer, since I'm not, but am willing to shoulder these tasks, I'll need some sponsership from a maintainer. Also will need advice regarding what to scan, etc (ie, I think we should scan a pre 2.1 merge, because the stability of the merged version could still be in question). Matt, thanks for taking the initiative. There's a problem with this automatic tests: They are geared to find security flaws. But, frankly, security is of little concern for Cinelerra. As Andraž has pointed out, there will be a lot of uninteresting bugs (like arrays of BC_TEXTLEN being filled with user input). I don't feel like fixing them because it's unlikely that they will flow upstream. The most interesting cases are missing or incorrect locking. _If_ the testing can find such bugs, and _if_ it can ignore (*) the forest of uninteresting flaws, it will be worth every penny and you have my support. (*) i.e. there is some means to filter them easily from the reports; plus klocwork will not feel abused because we don't fix these bugs. -- Hannes Anyway I need to respond to the klockwork guys. So are maintainers willing to work with me and accept patches based on scanning tools? thanks -matt ps. Here's the klockwork response. Hi Matt, Yes, we can build your code and analyze it for defects and security vulnerabilities. The offer we have for open source communities is that we will analyze your code on a periodic basis as long as Cinelerra is getting value from the results. The only thing we ask in return is that if any reported bugs make it into your fix process, you provide credit to Klocwork. We hope you see that as a fair deal!! Are you a core maintainer? We want to ensure that core maintainers are involved in any analysis since, as you can imagine, there's thousands of contributors to open source and we wouldn't have the resources to respond to all their individual requests. I look forward to hearing from you. Cheers, Adam Harrison [EMAIL PROTECTED] ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Suse 10.1 Error on make
On Monday 14 August 2006 06:45, Daniel Jircik wrote: I'm getting an error on make, with SVN and Heroines source on a new suse 10.1 install AMD 64x2 Heres the message Thanks in advance Daniel +++ Error on make SVN HVIRTUAL +++ BITS=64 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./.. -g -O2 -MT x264.lo -MD -MP -MF .deps/x264.Tpo -c x264.c -fPIC -DPIC -o .libs/x264.o x264.c: In function 'X264_init': x264.c:139: error: 'struct anonymous' has no member named 'b_cbr' Get an _older_ version x264. If you are not using the h264 encoder, you can also edit /usr/include/x264.h to add int b_cbr; at line 249. (But this will likely crash the encoder if you change your mind and use it.) -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Some Cinelerra newbie questions
On Thursday 10 August 2006 17:59, [EMAIL PROTECTED] geerts wrote: First major problem: keyframe edits are not saved, and (even worse) are *all* reset to default when undoing anything. This way, hours of painstaking audio or video adjustments can be lost with one careless touch of the 'z' key. I suspect this is a bug, but I'm not completely sure. Could I have missed some crucial setting? This is a bug in the CV version that was fixed on Oct 7 2005 (revision 676). -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Thanks for the response
Am Dienstag, 8. August 2006 11:44 schrieb Vaughan Famularo:
So far, I have downloaded the latest stable svn version and cannot get
past an error
which is
rm -fr .libs/libavcodec.lax
mkdir .libs/libavcodec.lax
rm -fr .libs/libavcodec.lax/libavcodeci386.a
mkdir .libs/libavcodec.lax/libavcodeci386.a
(cd .libs/libavcodec.lax/libavcodeci386.a ar
x /home/vaughan/Cinelerra
svn/hvirtual/quicktime/ffmpeg/libavcodec/i386/.libs/libavcodeci386.a)
Don't use paths with spaces ('Cinelerra svn').
-- Hannes
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Mixx2005 fails on Make
On Thursday 27 July 2006 01:36, glenn greenfield wrote: make is complaining that libmpeg3/i686/c_flags does not exist and for good reason. libmpeg3/i686 does not get created until after you run make for the first time. A second make fails due to a missing quicktime/i686 dir. It also is non-existent and here I am stuck. Glenn Greenfield In both of the files, the first error message appears in line 3. Start your investigations there. It is unlikely that you get more info here, since we talk more about cinelerra than mix2005. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra v2.1 has been Released
On Wednesday 05 July 2006 23:45, Johannes Sixt wrote: Just a brief notice - Pierre and I are working on the merge. The merge is progressing slowly, but it should pick up pace now that we have our infrastructure sorted out. I would like to thank Pierre that he's going through all the hassle to learn git[1] and cogito[2] just because I wanted to use theses tool sets. I am confident that it pays off in the end. This time we are going to be a lot more careful with the merge than I was with the merge of 2.0. For this reason, don't expect quick results. Please pick revision 836 if you want to stay at the last known working svn version. [1] http://www.kernel.org/pub/software/scm/git/docs/git.html [2] http://www.kernel.org/pub/software/scm/cogito/README -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra compilation
On Monday 26 June 2006 23:36, Richard Korinek wrote: I have possibly a silly question, but I cannot find the answer. Is it possible to have a standard libdv library on the system (in /usr] but compile and use cinerella against another library e.g. in /usr/local? I cannot find a solution so far and I need the system wide library for keeping the dependencies on gentoo. Thanks a lot for any answer. Normally, gcc is set up to pick up /usr/local before /usr. Therefore, what you want to achieve should happen automatically. Note that /etc/ld.so.conf is usually set up such that shared libraries in /usr/local/lib are prefered over those in /usr/lib. This happens regardless of from which path the library was linked as long as the one in /usr/local/lib has a suitable version number. This means that the presence or absence of /usr/local/lib/libdv.so.* when the application is *run* makes a difference. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra CVS compile error:dsputil_mmx
On Friday 16 June 2006 16:28, Leonardo wrote: Hi all, I'm compiling cinelerra cvs, checked-out this week, on a Gentoo Linux box, but it stops with the following error: gcc -DHAVE_CONFIG_H -I. -I. -I../../../.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MMX -DUSE_MMX -DX86_CPU -DHAVE_MMX -msse -DHAVE_BUILTIN_VECTOR -O3 -D_GNU_SOURCE -DHAVE_AV_CONFIG_H -I./../.. -g -O2 -MT dsputil_mmx.lo -MD -MP -MF .deps/dsputil_mmx.Tpo -c dsputil_mmx.c -o .libs/dsputil_mmx.o In file included from dsputil_mmx.c:140: dsputil_mmx_rnd.h: In function `put_no_rnd_pixels8_l2_mmx': dsputil_mmx_rnd.h:61: error: can't find a register in class `BREG' while reloading `asm' This file *must* be compiled with -O3. Appearently, you have used CFLAGS='-g -O2'. (most likely implicitly by not providing any flags to ./configure). Recompile this file without these flags: cd quicktime/ffmpeg/libavcodec/i386 make -k # builds everything in this dir, but fails for some make CFLAGS= # builds the failed ones again cd ../../../.. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] do you have cinelerra on Suse 10.1?
On Thursday 15 June 2006 22:27, Yama Ploskonka wrote: I'd really want to get in touch with people using Suse - I want to teach my 8th graders to use it, and would prefer Suse 10.1 for other stuff. Or maybe I should chose another distro, more popular among Cineler-ers. I've cinelerra running on Suse 10.1. I had to install these packages from a mirror of this list: ftp://packman.links2linux.de/pub/packman/MIRRORS x264 x264-devel libiec61883 libiec61883-devel faac faad2 faad2-devel a52dec (not sure about the two faad2 packages, though). To install them, fire up Yast, and add the mirror as an Add on product, like for example: http://packman.inode.at/suse/10.1/ The rest of the prerequisites is on the Suse DVD. Don't forget to install the -devel packages (most notably flac-devel, which is not resolved automatically) as well as nasm, otherwise the build fails. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Websvn, cvs commits
On Thursday 08 June 2006 03:08, Kevin Brosius wrote: I see your version has a commit list, which I haven't found out how to view in viewvc yet... svn log -r 800:HEAD is good enough for me, if I really need a list of revisions. I'm usually much more interested in which revisions touch a file and the corresponding diff. And every now and then I also need the annotate feature. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] 60i - 24p slow motion
On Monday 29 May 2006 19:27, Joe Stewart wrote: On Monday 29 May 2006 12:50 pm, Andraz Tori wrote: I am bit on the shaky grounds here, since i don't know what is acutally happening... Couldn't you do it by just using frames to fields and reframe plugins? Are you talking about setting asset fps to 15, project fps to 30, and then reframeRT at 0.8 scale? It makes an approximation but it wouldn't be smooth and it wouldn't be rendered at 24fps. What you end up with is a pseudo-24fps 30fps file which repeats every 4th frame to fill the time. No. Render Fields-To-Frames to a new file. Then import it. In the assets, specify that it is 24fps. Make your project frame rate also to 24fps. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] 60i - 24p slow motion
On Monday 29 May 2006 21:03, Joe Stewart wrote: As it works now, Frames-to-Fields takes alternating fields from the asset and makes frames in the timeline. Which seems to suggest it would be better named Frames-from-Fields. Or am I just thinking about it wrong? Indeed, you are right. The effect's icon, otoh, is quite clear. Unfortunately, it's quite difficult to fix this since the plugin name appears in project files :-( -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: Bezier curve alternative?
On Friday 26 May 2006 01:12, Ichthyostega wrote: There seems to be another Problem: If I am informed right, Cinelerra uses this bezier-courve feature for all Plugin Autos as well. Is this correct?? As far as I can tell, this is not correct. Plugins usually interpolate the parameters linearly. Only the autos that are represented as lines in the timeline interpolate with bezier curves. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Bezier automation
On Friday 26 May 2006 18:17, Ichthyostega wrote: Hi all, just another question to the cinelerra source code gurus -- what is the standard procedure if you want to extend some object with a new property? I can figure out how to save and re-read property values from the session XML. But what is your policy to handle old XML? Is there a version numbering of session file formats somewhere? Is there a migration component somehwere or is it the responsibility of every single component to handle missing values or migrate old values? First of all, you should ensure that the extension is a proper superset of the old functionality, so that no functionality gets lost. Then I'd only ensure forward compatibility and care about backward compatibility only if it is easy to achieve. (If someone disagrees, please speak up!) Then when you read in an XML file, just make sure you check for old properties and values and translate them to the new settings. Each component is itself responsible to handle the migration; there is no general migration component. There is a version number somewhere, but at the moment I don't see much of a use for it. Currently it is identical to the program's version number, I think. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] SVN Changelog - What's new ?
On Saturday 13 May 2006 19:43, Nicolas wrote: Hello, I use Cinelerra SVN revision 786. I downloaded the latest SVN, and the revision number is now 789. What's new compared to my 786 version? I looked at the Changelog file, but it's not updated anymore. Generally speaking, is there a way to know what's new in the SVN versions? svn log -r786:789 and if you want to see the details svn diff -r786:789 -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Intel 820 D (2.8GHz) vs Athlon64 3400 ?
On Tuesday 02 May 2006 11:28, Marcin Kostur wrote: Dear C2-Users 820 D and athlon64 3400 systems have similar price In theory 820D is faster - 30-50%. What whould you recommend to get considering: No recommendations, just answering questions: 1) Can cinerella use effectively both cores for rendering? Yes. 2) Can cinelerra use effectively both cores for playback (with effects). Yes. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Cinelerra with shared Libs
On Sunday 23 April 2006 12:36, Eddy Nigg (StartCom Ltd.) wrote: Hi, I'm currently preparing our new StartCom MultiMedia Edition ML-5.0.5 which is based on the new Fedora Core 5 (That's a switch from previously RHEL as underlying OS) Current Cinlerra version 2.0 can't be compiled on FC5, and may patches have to be applied to various libraries (Faac, Faad, Libdv etc). I did not got to the point yet to compile cinelerra itself, because I would prefer that it would be linked to the system libraries and not the libs provided in the cinlerra package. I wonder, if there are a few tips for doing that, before I kneel into this and do it by ourself. Download the community version as per http://cvs.cinelerra.org/svnusage.html which is probably what you are looking for. It uses auto* tools build system and uses the libraries provided by the system instead of its own copies. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Issues compiling original HV under FC5
On Saturday 22 April 2006 06:02, Pierre Marc Dumuid wrote: Hi all, I am having difficulties compiling the Upstream (non-SVN) version of cinelerra. I have a few patches that I wrote that I was going to apply to the upstream version of cinelerra and send upstream (such as the sort by filename extension.) I use Fedora, (which it seems heroine uses as well I think) but I have recently updated to FC5. When I attempt to compile, (for gcc 4.1.0) I had a whole heap of errors. I have squashed most of these in the attached patch, (the libdv-0.104 had too many errors, so I merged the HV's code with the current libdv CVS). I managed to squash all of them except one, which I don't have a clue as to what it is. [EMAIL PROTECTED] mpeg2enc]$ make gcc -c `cat i686/c_flags` mblock_sub44_sads.c -o i686/mblock_sub44_sads.o mblock_sub44_sads_x86_h.c: In function mblock_sub44_dists_mmxe: mblock_sub44_sads.c:72: error: invalid 'asm': invalid constraints for operand mblock_sub44_sads.c:79: error: invalid 'asm': invalid constraints for operand mblock_sub44_sads.c:81: error: invalid 'asm': invalid constraints for operand make: *** [i686/mblock_sub44_sads.o] Error 1 That is the output, and the error occurs from the lines: movq_m2r( *blk, mm0); blk += rowstride; movq_m2r( *blk, mm1); // Line 72 Have you noticed that movq_m2r is a macro defined in mpeg2enc/mmx.h that expands to to inline assembly? I'm not speaking gcc assembly fluently enough to fix the error, though. -- Hannes if( h == 2 ) return; movq_m2r( *blk2, mm2); // Line 79 blk2 += rowstride; movq_m2r( *blk2, mm3); // Line 81 temporarily removing line 71, gets rid of error for line 72, but I really don't understand this error. Anyone have any clues?? Pierre ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] chromakey-hsv math error
Oops, no! This will all your footage, because... On Monday 10 April 2006 15:46, Jerome Cornet wrote: - as = (s - sat - min_s / min_s) / 2; + as = as = (s - sat - min_s) / (min_s * 2); ... this is undefined behavior: as is modified twice! ;)) Did you mean this? + as = (s - sat - min_s) / (min_s * 2); -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] problem running autogen.sh on latest cvs
On Saturday 08 April 2006 08:48, Scott C. Frase wrote: Guys, I've checked out the latest code and run autogen.sh and get the following message: [EMAIL PROTECTED] hvirtual]# ./autogen.sh User defined paths to the preferred autoconf and automake versions. Read the script if you would like to modify them. AUTOMAKE=automake ACLOCAL=aclocal AUTOCONF=autoconf AUTOHEADER=autoheader Now building the ./configure script... checking for automake version... 1.9 checking for aclocal version... 1.9 Running aclocal -I m4 ... Running libtoolize ... You should update your `aclocal.m4' by running aclocal. Running autoheader ... Running automake ... configure.in: installing `./install-sh' configure.in: installing `./missing' cinelerra/data/Makefile.am:1: library used but `RANLIB' is undefined cinelerra/data/Makefile.am:1: cinelerra/data/Makefile.am:1: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB' cinelerra/data/Makefile.am:1: to `configure.in' and run `autoconf' again. plugins/defaulttheme/data/Makefile.am:1: library used but `RANLIB' is undefined plugins/defaulttheme/data/Makefile.am:1: plugins/defaulttheme/data/Makefile.am:1: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB' plugins/defaulttheme/data/Makefile.am:1: to `configure.in' and run `autoconf' again. plugins/suv/data/Makefile.am:1: library used but `RANLIB' is undefined plugins/suv/data/Makefile.am:1: plugins/suv/data/Makefile.am:1: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB' plugins/suv/data/Makefile.am:1: to `configure.in' and run `autoconf' again. quicktime/ffmpeg/libavcodec/Makefile.am:13: Libtool library used but `LIBTOOL' is undefined quicktime/ffmpeg/libavcodec/Makefile.am:13: quicktime/ffmpeg/libavcodec/Makefile.am:13: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' quicktime/ffmpeg/libavcodec/Makefile.am:13: to `configure.in' and run `aclocal' and `autoconf' again. quicktime/ffmpeg/libavcodec/i386/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined quicktime/ffmpeg/libavcodec/i386/Makefile.am:1: quicktime/ffmpeg/libavcodec/i386/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' quicktime/ffmpeg/libavcodec/i386/Makefile.am:1: to `configure.in' and run `aclocal' and `autoconf' again. I did update aclocal by running 'aclocal' as suggested, but it does not help. I am running Fedora Core 4, using version 1.9 of automake and aclocal and version 2.59 of autoconf. Not sure what to do. Please help. scott Instead of ./autogen.sh try: autoreconfig or autoreconfig -i -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] problem running autogen.sh on latest cvs
On Saturday 08 April 2006 21:55, Scott C. Frase wrote: Hi Hannes, Here is what I have: [EMAIL PROTECTED] hvirtual]# rpm -qa | grep libtool libtool-debuginfo-1.5.16.multilib2-3 libtool-libs13-1.3.5-10 libtool-1.5.16.multilib2-3 libtool-ltdl-1.5.16.multilib2-3 [EMAIL PROTECTED] hvirtual]# libtool --version ltmain.sh (GNU libtool) 1.5.16 (1.1220.2.235 2005/04/25 18:13:26) [EMAIL PROTECTED] hvirtual]# ll /usr/share/aclocal/libtool.m4 -rw-r--r-- 1 root root 219425 Nov 22 08:18 /usr/share/aclocal/libtool.m4 [EMAIL PROTECTED] hvirtual]# ll aclocal.m4 -rw-r--r-- 1 root root 38761 Apr 8 11:05 aclocal.m4 Your aclocal.m4 is much too short. It must be a superset of /usr/share/aclocal/libtool.m4. But I cannot tell why this is so. I hope you can debug it yourself. Start with the aclocal command: It looks into configure.in which macros are required and gathers them from the various sources, among which are /usr/share/aclocal and the m4 subdirectory in cinelerra. Also remove the autom4ate.cache directory. -- Hannes ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
