[CinCV] UTF-8 encoded files name display
Hi, is there a way to get correct display of UTF-8 encoded file names in cinelerra file dialogs ? How about the internal handling of such file names ? Do I have to expect problems when saving/loading projects referencing filenames including "non 7-bit ASCII characters" ? Most of the modern Linux distributions have switched to UTF-8 (RedHat,Suse,Ubuntu,...). And I appreciate this step. But cinelerra seems to be one of my few applications, which cause trouble. By the way, my locale is set to de...@utf-8. And I'm not talking about menu translations / localization issues. Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] UTF-8 encoded files name display
Hi, is there a way to get correct display of UTF-8 encoded file names in cinelerra file dialogs ? How about the internal handling of such file names ? Do I have to expect problems when saving/loading projects referencing filenames including "non 7-bit ASCII characters" ? Most of the modern Linux distributions have switched to UTF-8 (RedHat,Suse,Ubuntu,...). And I appreciate this step. But cinelerra seems to be one of my few applications, which cause trouble. By the way, my locale is set to de...@utf-8. And I'm not talking about menu translations / localization issues. Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] include order in ffmpeg.h
Now, what's the default location of avcodec.h and swscale.h after installing ffmpeg it from source ? Are we both dealing with ffmpeg code newer than 2008-04-14 ? I didn't compile ffmpeg myself, as I'm using Christian Marrilats Debian packages from debian-multimedia.org. Therefore, I'm a little bit confused about the include file locations. /usr/include/ffmpeg/libavcodec/avcodec.h /usr/include/ffmpeg/libswscale/swscale.h /usr/include/ffmpeg/libavformat/avformat.h ... Is this new hierachical organization Christians own creation ? Is he following some Debian specific guidelines, or is this a general change of the ffmpeg defaults ? Maybe it's a good idea - for the moment - to adapt the configure system to include these optional subfolders. Toby > -Ursprüngliche Nachricht- > Von: cinelerra@skolelinux.no > Gesendet: 22.04.08 18:06:41 > An: cinelerra@skolelinux.no > Betreff: Re: [CinCV] include order in ffmpeg.h > afaik, > cinelerra does compile OK with latest ffmpeg. > When I applied the latest external ffmpeg api fix, it compiled fine (ffmpeg > installed from source). > > bye, > rafael diniz > > Em Monday 21 April 2008, Herman Robak escreveu: > > On Mon, 21 Apr 2008 13:49:03 +0200, toby <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > today I've tried to compile the latest r1056 on debian unstable with > > > external ffmpeg, libavcodeccvs51 version 3:20080414. > > > There have been two main issues, that needed some fixing. > > > > ...snip... > > > > > Is it required to fix SVN code, or is cinerella not intended to work > > > with latest ffmpeg ? > > > > Unless we explicitly state otherwise, users will assume that it does. > > So I'd say this needs fixing. Committers? > > > > -- > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > Ciência da Computação @ Unicamp > Rádio Muda, radiolivre.org, TV Piolho, tvlivre.org, www.midiaindependente.org > Chave PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2FF86098 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > > > ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCV] Default range for video fade
Hi, yesterday I got in trouble with the range settings for video fade. It took me quite a while to recognize that the range was set to [0;1]. To track the problem, I had also switched into a clean dummy account with an empty $HOME folder. And surprisingly, the "default" setting was [0;1] instead of the expected [0;100]. What's responsible for the default settings ? A default file, which might be corrupt or some code ? Has anyone else observed such strange default settings, too? To exclude any issues with my self-compiled version (latest Debian unstable / gcc 4.2), I've installed Christian Marillats packages from www.debian-multimedia.org as well and saw the same problems. Might be a general problem. Any comments ? Toby
[CinCV] include order in ffmpeg.h
Hi,
today I've tried to compile the latest r1056 on debian unstable with
external ffmpeg, libavcodeccvs51 version 3:20080414.
There have been two main issues, that needed some fixing.
a) header location:
Latest ffmpeg/avcodec headers are now installed in /usr/include/ffmpeg,
/usr/include/ffmpeg/libavcodec, and libswscaler, respectively.
Is anyone on this list familiar with latest ffmpeg ? Is it suggested to
expand/adapt
the include path, or should we only include /usr/include/ffmpeg and
change code to
"#include ", etc. ?
b) conflicting header include order:
In the updated ffmpeg.h, the include section of swscaler/ffmpeg, which
is wrapped
inside a extern "C" statement, is place before "#include "guicast.h".
This gave me a
bunch of "template with C linkage" error, which is sometimes called
'dangling extern "C"'
(http://www.gidforums.com/t-9853.html).
To fix this one it was just a matter of reordering the includes:
#include "guicast.h"
#ifdef HAVE_SWSCALER
extern "C" {
#include "ffmpeg.h"
#include
}
#endif
Is it required to fix SVN code, or is cinerella not intended to work
with latest ffmpeg ?
Toby
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: Re: [CinCVS] Make cinelerra work with swscaler enabled ffmpeg
Hi Alexis, looks like svn code hasn't seen any update regaring the issue with swscale enabled external ffmpeg. Here is what I had to do to compile latest SVN on a Debian system utilizing external ffmpeg (libavcodeccvs51) provided by Christian Marillat on http://www.debian-multimedia.org/, which has swscale enabled. First of all, it turned out that link stage (g++) was not able to find any of the avcodec_* functions, because they are "C". Wrapping the ffmpeg/avcodec includes of fileac3.C and ffmpeg.C into extern "C" statements did the trick. Maybe this is a completely sick approach, but at least g++ seems to be happy at link time. If anyone knows how to do better, please let me know ! Second, latest libavcodeccvs51 is built with swscale support enabled. Therefor it was necessary to apply some part of your patch manually (ffmpeg.C and adjustments to the Makefile -> this was faster than editing configure etc. and re-run everything from scratch) So, here's my request to merge this patch (maybe in some adapted version or anything similar) into SVN. Having broken SVN code when it comes to external ffmpeg with enabled swscale is a pretty bothersome situation. The absolut minimum should be merge the configure code to check for a swscale enabled external ffmpeg and give a meaningfull error message ! This would have saved me from several hours of trial and error. Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] transfering camera/projector automation (keyframes) between projects
Hi, is there a way to transfer camera/projector automation, I mean the corresponding keyframes, from one project to another for reuse ? Let's say I'd like to transfer a nice and fancy fade between two tracks to a different project? As a fall-back: How do I exchange the footage of a track without loosing keyframes ? I've created an animated DVD menu with a 3x2 array of tiny previews (short clips, not just static thumbnails). I'd like to reuse this arrangement for a new DVD menu by simply exchanging the clips (and title line). Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: Re: [CinCVS] Why OpenGL does not affect rendering, It just accelerates playback?
Craig, I think it should be possible to get rendered output without the use of proprietary toolkits. Plain OpenGL should do as well by rendering into a (hidden) texture and calling something like glGetTexImage() to access the rendered output. I'm not an OGL programmer, but I've read about this kind of techniques many times. glReadPixels() provides basic access to the actual "frame buffer" of the rendered screen content. But since the output window might not be at full resolution, this is not a solution. In general, it should be possible to make use of OpenGL for rendering, too. Just look at all the OGL based hardware-acceleration stuff they're working on for vector libraries like cairo/glitz. Toby > Hi Craig, > > I don't understand what you said. I thought that nvidia cg offers frame > buffer object to read data back from graphics card. > > Regards > Leigh > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Craig Lawson > Sent: Monday, 12 March 2007 8:29 p.m. > To: cinelerra@skolelinux.no > Subject: Re: [CinCVS] Why OpenGL does not affect rendering, It just > accelerates playback? > > > The graphics processor on the video card is not designed to send > rendered output back to the main processor. OpenGL instructions come in > one end, and rendered output goes out the other end ... to the monitor. > > It's unfortunate we can't intercept this data. Solid modelers such as > Blender could probably use it, too. Maybe someday there will be enough > market demand for the hardware to change. > > Craig. > > > Leigh Wanstead wrote: > > Hello everyone, > > > > I read this url. > > > http://cvs.cinelerra.org/docs/split_manual_en/cinelerra_cv_manual_en_3.html# > SEC41 > > > > May I ask why OpenGL does not affect rendering, It just accelerates > > playback? What is the reason? > > > > TIA > > > > Regards > > Leigh > > www.smootharm.com <http://www.smootharm.com/> > > ___ > 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 > ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Support for a fast decoding lossless codec ?
Hi, how about adding input support for a fast decoding lossless codec ? Since ffmpeg is already used for some other codecs, I would love to see support for one of the lossless codecs contained in ffmpeg/lavc. MPNG would be very high quality with 24-bit colorspace support, but it's not the fastest one in terms of decoding speed, which would imply additional resources for decoding during editing. After playing around with all lossless or nearly lossless codecs, FFV1 seems to be pretty fast. Restricting it to a target colorspace of YV12 can speed up things,too. Is there any faster decoding lossless codec out there ? The ffmpeg wavelet based SNOW codec looks promising, too. But it's still experimental. What do other people on this list think about lossless codec support in cinelerra ? I'm talking about source footage, and not export ... Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering hangs/crashes for multitrack composition
Hi Andraz, here's the gdb bt output for the interesting thread, which caused the crash during rendering: Thread 163 (Thread 565124016 (LWP 9290)): #0 0xb741398c in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7ac0c25 in mpeg3io_read_data (buffer=0x0, bytes=2092344, fs=0xbdc628e0) at mpeg3io.c:107 #2 0xb7ac569c in mpeg3_read_toc (file=0xbfa7e008, atracks_return=0x21aea298, vtracks_return=0x21aea294) at mpeg3tocutil.c:158 #3 0xb7aba677 in mpeg3_get_file_type (file=0xbfa7e008, old_file=0x0, toc_atracks=0x21aea298, toc_vtracks=0x21aea294) at libmpeg3.c:293 #4 0xb7abae62 in mpeg3_open_copy ( path=0x21aeaf10 "/home/toby/.bcast/[EMAIL PROTECTED]", old_file=0x0, error_return=0x21aeb344) at libmpeg3.c:428 #5 0xb7abb19a in mpeg3_open ( path=0x21aeaf10 "/home/toby/.bcast/[EMAIL PROTECTED]", error_return=0x21aeb344) at libmpeg3.c:547 #6 0x081c0796 in FileMPEG::create_index (this=0xb93fbf60) at filempeg.C:529 #7 0x081c1217 in FileMPEG::open_file (this=0xb93fbf60, rd=1, wr=0) at filempeg.C:196 #8 0x0819f0ac in File::open_file (this=0xbd3f7e78, preferences=0x9f09e1d0, asset=0xbdc4df40, rd=1, wr=0, base_samplerate=-1, base_framerate=-1) at file.C:546 #9 0x0814512a in CICacheItem (this=0xb93f3cf0, cache=0x4572a190, edl=0x4576d090, asset=0x4578c808) at cache.C:367 #10 0x081459e8 in CICache::check_out (this=0x4572a190, asset=0x4578c808, edl=0x4576d090, block=1) at cache.C:79 #11 0x082d0648 in VModule::import_frame (this=0x457a06b8, output=0x457aa8f8, current_edit=0x4578f5c8, input_position=0, frame_rate=25, direction=0, use_opengl=0) at vmodule.C:131 #12 0x082d0fde in VModule::render (this=0x457a06b8, output=0x457aa8f8, start_position=0, direction=0, frame_rate=25, use_nudge=0, debug_render=0, use_opengl=0) at vmodule.C:521 #13 0x082cfe49 in VirtualVNode::read_data (this=0x457a2108, output_temp=0x457aa8f8, start_position=0, frame_rate=25, use_opengl=0) at virtualvnode.C:147 #14 0x082d0085 in VirtualVNode::render_as_module (this=0x457a2108, video_out=0x457a2b40, output_temp=0x457aa8f8, start_position=0, frame_rate=25, use_opengl=0) at virtualvnode.C:244 #15 0x082d0143 in VirtualVNode::render (this=0x457a2108, output_temp=0x457aa8f8, start_position=1125903123083272, frame_rate=25, use_opengl=0) at virtualvnode.C:166 #16 0x082cf47f in VirtualVConsole::process_buffer (this=0x457a1578, input_position=0) at virtualvconsole.C:152 #17 0x082d40b0 in VRender::process_buffer (this=0x4576cc58, input_position=0) at vrender.C:184 #18 0x082d41c8 in VRender::process_buffer (this=0x4576cc58, video_out=0x457a2b40, input_position=0, last_buffer=0) at vrender.C:97 #19 0x08249fc9 in PackageRenderer::do_video (this=0x21aefc0c) at packagerenderer.C:363 #20 0x0824abd8 in PackageRenderer::render_package (this=0x21aefc0c, package=0x44e26d08) at packagerenderer.C:580 #21 0x0828e4c8 in Render::render (this=0x9398940, test_overwrite=1, asset=0xdccd758, edl=0x9f4c0100, strategy=0) at render.C:776 #22 0x0828f275 in Render::run (this=0x9398940) at render.C:366 #23 0xb7b8384f in Thread::entrypoint (parameters=0x9398940) at thread.C:48 #24 0xb75f3240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #25 0xb747229e in clone () from /lib/tls/i686/cmov/libc.so.6 Since I kept on working with MPEG2 footage under supervision of gdb, I was able to backtrack another crash, which occured during copy&paste editing. It also points to the same root cause: mpeg3io_read_*. Thread 26 (Thread -1531348048 (LWP 12960)): #0 0xb7a943c6 in mpeg3io_read_char (fs=0xbfa017e8) at mpeg3protos.h:682 #1 0xb7a9463f in mpeg3io_read_int32 (fs=0x1) at mpeg3protos.h:700 #2 0xb7a954ef in mpeg3demux_read_program (demuxer=0x357a008) at mpeg3demux.c:1429 #3 0xb7a9694a in mpeg3_read_next_packet (demuxer=0x357a008) at mpeg3demux.c:1786 #4 0xb7a99d4b in mpeg3_create_title (demuxer=0x357a008, toc=0x0) at mpeg3title.c:165 #5 0xb7a93096 in mpeg3_open_copy ( path=0xbfa03ba8 "/media/anim_dvd_background/tech_loops_pal.m2v", old_file=0x0, error_return=0xa4b92408) at libmpeg3.c:463 #6 0xb7a9319a in mpeg3_open ( path=0xbfa03ba8 "/media/anim_dvd_background/tech_loops_pal.m2v", error_return=0xa4b92408) at libmpeg3.c:547 #7 0x081c11ef in FileMPEG::open_file (this=0xbfa00be0, rd=1, wr=0) at filempeg.C:172 #8 0x0819f0ac in File::open_file (this=0xbfa00ab8, preferences=0x8554aa8, asset=0xbfa01dd0, rd=1, wr=0, base_samplerate=0, base_framerate=0) at file.C:546 #9 0x081e94c5 in MainIndexes::add_next_asset (this=0x92d5600, file=0x0, asset=0xbfa01dd0) at mainindexes.C:73 #10 0x08215492 in MWindow::paste_edls (this=0xbfe8fe54, new_edls=0xa4b939f4, load_mode=5, first_track=0x0, current_position=16.199, edit_labels=1, edit_plugins=1, overwrite=0) at mwindowedit.C:1433 #11 0x08215ccc in MWindow::insert (this=0xbfe8fe54, position=16.199, file=0xa4b93a5c, edit_labels=1, edit_plugins=1, parent_edl=0x0) at mwindowedit.C:594 #12 0x0821693c in MWindow::paste (this=0xbfe8fe54) at mwindowedit.C:1074 #13 0x081ec624 in Paste::handle_event
Re: [CinCVS] Rendering hangs/crashes for multitrack composition
Thanks for all your feedback ! Since I don't have any adjacent clips on my timeline, there shouldn't a problem with gaps. Furthermore, I used a build newer than r952 for the creation, so snapping should have worked. Meanwhile, I figured out how to get my project rendered: I had to render all full size background tracks into an intermediate file and place this single, non-MPEG2 footage, instead of the background MPEG2 material. Then, rendering worked fine. Looks like reducing the number of concurrent MPEG2 files, from 7 to 6, helped to get the job done. Since playing with gdb indicated that the crash might happen somewhere inside libmpeg3 while reading a frame, I'm wondereing whether there's a problem with MPEG program streams including NAV packages ? Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Rendering hangs/crashes for multitrack composition
Hi Andraz, I haven't used gdb in heavily multi-threaded environments like cinelerra yet. But the output I was able to achive up to now told me that there's some memcpy problem somewhere in libmpeg3 reading a frame. Until I'm done with my reading about gdb and threads, here's what strace tells me: Any ideas ? futex(0x858238c, FUTEX_WAIT, 1, NULLRender::run 1 Render::run 2 Render::run 3 Render::run 4 Render::run 5 Render::run 6 Render::run 7 Render::run 8 Render::run 8.1 Render::run 8.2 Render::run 8.3 Render::run 9 Render::run 10 signal_entry: got SIGSEGV my pid=17307 execution table size=16: filempeg.C: open_file: 496 filempeg.C: read_frame: 1174 filempeg.C: read_frame: 1180 filempeg.C: read_frame: 1209 filempeg.C: open_file: 164 filempeg.C: open_file: 496 bchash.C: copy_from: 255 bchash.C: copy_from: 258 bchash.C: copy_from: 267 filempeg.C: read_frame: 1174 filempeg.C: read_frame: 1180 filempeg.C: read_frame: 1209 bchash.C: copy_from: 255 bchash.C: copy_from: 258 bchash.C: copy_from: 267 filempeg.C: open_file: 164 signal_entry: lock table size=21 0x926d668 CWindowTool::input_lock CWindowTool::run 0x8582388 BC_Synchronous::next_command BC_Synchronous::run 0x9322358 TransportQue::output_lock PlaybackEngine::run 0x9322938 MainIndexes::input_lock MainIndexes::run 1 0x9291c40 TransportQue::output_lock PlaybackEngine::run 0x9b7c248 LoadClient::input_lock LoadClient::run 0x9b7c4a0 LoadClient::input_lock LoadClient::run 0x9280600 LoadClient::input_lock LoadClient::run 0x9381350 ResourceThread::draw_lock ResourceThread::run 0x93af360 BC_Repeater::pause_lock BC_Repeater::run 0x9a8dc58 FileThread::output_lock FileThread::run 1 0xa104d58 LoadClient::input_lock LoadClient::run 0xa101758 LoadClient::input_lock LoadClient::run 0x9f92158 LoadClient::input_lock LoadClient::run 0x9be19d0 CICache::total_lock CICache::check_out * 0x93246f0 BC_WindowBase::event_condition BC_WindowBase::get_event 0x8df69e8 BC_WindowBase::event_condition BC_WindowBase::get_event 0x92aba88 BC_WindowBase::event_condition BC_WindowBase::get_event 0x9201a18 BC_WindowBase::event_condition BC_WindowBase::get_event 0x9293230 BC_WindowBase::event_condition BC_WindowBase::get_event 0x93b0920 BC_WindowBase::event_condition BC_WindowBase::get_event BC_Signals::dump_buffers: buffer table size=0 BC_Signals::delete_temps: deleting 0 temp files SigHandler::signal_handler total files=1 Closing /media/slideshows/parties/fg.mov ) = -1 EINTR (Interrupted system call) +++ killed by SIGABRT +++ Process 17307 detached Andraž Tori wrote: > try to run it through gdb ... we'll at least have an idea where it > crashes... > > though by the look of things this is some kind of memory trashing... so > it's going to be hard to track it down. if you are familar with gdb, it > might help > > bye > andraz > ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Rendering hangs/crashes for multitrack composition
Hi, yesterday I worked on some DVD menus, where I placed 6 video tracks with DVD-MPEG2 footage (arrangement of animated previews) on top of an animated background. Except for some resource shortage there's no problem with playback, etc. But when it comes to rendering, it only worked sporadically for some of my compositions. Most of the time cinelerra hangs or crashes during rendering regardless which output format I chose. Looking at the projects that worked and the ones which didn't doesn't show any obvious difference. Exactly the same arrangements, where I just swaped all the source material. First, I thought the problem is related to a certain track or source footage, but disabling an arbitrary track helps most of the time. Now, is there a limit in video tracks that can be used for compositions in parallel ? (I'm talking about 2 full-size background tracks and 6 partial preview areas visible at the same time) Are there known problems with MPEG2 source footage ? Any other ideas ? Would it be worth analyzing the XML project files for some "irregular" stuff? By the way, I'm talking about the latest debian packages as well as an up-to-date SVN build as of 3/12/06. No matter whether utilizing OpenGL or not. Toby ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] cinelerra 2.1 debian packages
Hi Andraz, do you have any plans to release packages with opengl support ? Toby Andraž Tori wrote: debian packages of 2.1 have been uploaded to the http://www.kiberpipa.org/~minmax/cinelerra repository they are not linked to the opengl... please report problems/submit fixes :) bye andraz ___ 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: Re: [CinCVS] new debian builds
Andra, I 'm faced with these crashes for several weeks now. I had decided to wait for updated packages at that time, because there was no urgent need to work with cinelerra. But the last two updates didn't change it. I've tested several effects on my own and a bare test account. Which versions are you using ? athlonxp , pentium4, ... ? Does rendering video effects work on your system ? And if yes : What video formats did you test ? What's your system status and kernel version ? I'm only working with DV (mov oder avi) footage coming from my camcorder grabbed with dvgrab or kino - not with cinelerra. Do you think it's worth converting it to a different format for testing purpose ? F.Y.I. ... I'm using Debian unstable + Christan Marillats video packages. My last distupgrade was about a week ago. Everything should be pretty recent. Toby > Has it happened with previous versions also? > > bye > andra? > > On pon, 2006-04-03 at 21:16 +0200, streumix wrote: > > Hi, > > > > I'm using the debian athlonxp packages from > > http://www.kiberpipa.org/~minmax/cinelerra/builds/athlonxp/. > > A few days ago I've noticed that rendering effects causes > > cinelerra to crash. This holds for the latest version > > 1:2.0.0-1svn20060402. Input footage is DV in avi or mov > > container. Output format or effect doesn't matter. > > Cinelerra crashes all the time. > > > > Is this a athlonxp only problem ? Anyone having the same > > problem with debian packages and rendering effects ? > > > > Toby > > > > > > > > > > > Subject: > > > [CinCVS] new debian builds > > > From: > > > Andraz Tori > > > Date: > > > Fri, 31 Mar 2006 10:41:28 +0200 > > > > > > To: > > > "cinelerra@skolelinux.no" > > > > > > > > >I've completed new debian builds of cinelerra, which among other > include > > >fixes for lately discovered transition length problem, more proper ogg > > >theora/vorbis encoding, new chromakey plugin... > > > > > >http://www.ftconsult.com/twiki/bin/view/Cinelerra/Debian > > > > > > > > >hopefully these are the last builds from me, since Jure is working on a > > >much better build infrastructure, that will enable having debian, > ubuntu > > >and maybe even fedora packages built at the same time. > > > > > >bye > > >andraz > > > > > > > > >___ > > >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 > > > ___ > 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
