Re: [CinCVS] [Bug 347] Crash on with title and reverb effects
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).
On 10/28/06, m h <[EMAIL PROTECTED]> wrote:
So using the same simple test case, I still get the other crash as
well. If anyone read's this they might wonder what the "MATT inbuf"
junk is below. Well I added some debug statements to try and figure
out what is happening. It appears the the plugin on
ReverbEngine class is getting set with a bad/junk plugin.
At line 505 of reverb.C I added the following 2 lines:
printf("MATT plugin: %d", plugin);
printf("MATT inbuf:%d", plugin->total_in_buffers);
for(i = 0; i < plugin->total_in_buffers; i++)
It appears to crash trying to derefence plugin->total_in_buffers (or
at least according to my debug statements it does).
$ cinelerra
Cinelerra 2.1CV SVN 948 (C) 2006 Heroine Virtual Ltd.
Binary built via ebuild script in Gentoo linux.
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.
Mutex::lock: Success
MATT plugin: 149401664MATT inbuf:1MATT plugin: 149401664MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 149107096MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 149107096MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 320signal_entry:
got SIGSEGV my pid=21818 execution table size=16:
vrender.C: run: 506
vrender.C: run: 414
vrender.C: process_buffer: 103
vrender.C: process_buffer: 113
vrender.C: run: 416
vrender.C: run: 427
vrender.C: run: 439
vrender.C: run: 477
vrender.C: run: 489
vrender.C: run: 493
vrender.C: run: 495
vrender.C: run: 504
vrender.C: run: 506
vrender.C: run: 414
vrender.C: process_buffer: 103
vrender.C: process_buffer: 113
signal_entry: lock table size=20
0x8bcc968 CWindowTool::input_lock CWindowTool::run
0x85ae4b8 BC_Synchronous::next_command BC_Synchronous::run
0x8c9b8b8 TransportQue::output_lock PlaybackEngine::run
0x8c9bee0 MainIndexes::input_lock MainIndexes::run 1
0x8d8a9f8 RotateEngine::input_lock RotateEngine::run
0x8e48370 (null) (null) *
0x8d078d0 ResourceThread::draw_lock ResourceThread::run
0x8bf0ef8 TransportQue::output_lock PlaybackEngine::run
0x8d35850 BC_Repeater::pause_lock BC_Repeater::run
0x85c0a20 AudioDevice::arm_lock AudioDevice::arm_buffer *
0x85c09e0 AudioDevice::arm_lock AudioDevice::arm_buffer *
0x8a33550 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8b56fc0 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8bf2550 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8d36e58 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8c16490 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8c9dcc8 BC_WindowBase::event_condition BC_WindowBase::get_event
0x85c0a00 AudioDevice::play_lock AudioDevice::run 1 *
0x8e6f8c8 OSSThread::write_lock OSSThread::wait_write
0x85c0a20 AudioDevice::arm_lock AudioDevice::arm_buffer
BC_Signals::dump_buffers: buffer table size=0
BC_Signals::delete_temps: deleting 0 temp files
SigHandler::signal_handler total files=0
Aborted (core dumped)
I loaded this up in gdb and it confirms that it crashed on line (which
appears to validate my suspicion).
My question is why this is happening?
Help please?
thanks
-matt
On 10/28/06, m h <[EMAIL PROTECTED]> wrote:
> Ok, simpler test case. Add reverb (concert hall sound effect) to
> track and it crashes occasionally when played.
> Heres the error:
>
> cinelerra: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion
> `mutex->__data.__owner == 0' failed.
> Aborted (core dumped)
>
> The backtrace on the core file says this:
>
> (gdb) bt
> #0 0xe410 in __kernel_vsyscall ()
> #1 0xb737c129 in raise () from /lib/libc.so.6
> #2 0xb737d553 in abort () from /lib/libc.so.6
> #3 0xb7375cbd in __assert_fail () from /lib/libc.so.6
> #4 0xb74961be in pthread_mutex_lock () from /lib/libpthread.so.0
> #5 0xb7a117d9 in Mutex::lock (this=0x8e622d0, location=0x0) at mutex.C:47
> #6 0xb24e0bdc in ReverbEngine::run (this=0x8e622b0) at reverb.C:501
> #7 0xb7a1ccd9 in Thread::entrypoint (parameters=0x8e622b0) at thread.C:48
> #8 0xb7494167 in start_thread () from /lib/libpthread.so.0
> #9 0xb740ab7e in clone () from /lib/libc.so.6
>
> Line 501 of reverb.C is this:
> input_lock.lock();
>
> I guess I need to read up on pthread locking.
>
> Anyway, can anyone help out here? Does this crash happen for other people?
>
> Should I file another bug for this?
>
> I'd
[CinCVS] New klocwork results...
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. thanks -matt ___ 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
So using the same simple test case, I still get the other crash as
well. If anyone read's this they might wonder what the "MATT inbuf"
junk is below. Well I added some debug statements to try and figure
out what is happening. It appears the the plugin on
ReverbEngine class is getting set with a bad/junk plugin.
At line 505 of reverb.C I added the following 2 lines:
printf("MATT plugin: %d", plugin);
printf("MATT inbuf:%d", plugin->total_in_buffers);
for(i = 0; i < plugin->total_in_buffers; i++)
It appears to crash trying to derefence plugin->total_in_buffers (or
at least according to my debug statements it does).
$ cinelerra
Cinelerra 2.1CV SVN 948 (C) 2006 Heroine Virtual Ltd.
Binary built via ebuild script in Gentoo linux.
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.
Mutex::lock: Success
MATT plugin: 149401664MATT inbuf:1MATT plugin: 149401664MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 149107096MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 149107096MATT
inbuf:1MATT plugin: 149107096MATT inbuf:1MATT plugin: 320signal_entry:
got SIGSEGV my pid=21818 execution table size=16:
vrender.C: run: 506
vrender.C: run: 414
vrender.C: process_buffer: 103
vrender.C: process_buffer: 113
vrender.C: run: 416
vrender.C: run: 427
vrender.C: run: 439
vrender.C: run: 477
vrender.C: run: 489
vrender.C: run: 493
vrender.C: run: 495
vrender.C: run: 504
vrender.C: run: 506
vrender.C: run: 414
vrender.C: process_buffer: 103
vrender.C: process_buffer: 113
signal_entry: lock table size=20
0x8bcc968 CWindowTool::input_lock CWindowTool::run
0x85ae4b8 BC_Synchronous::next_command BC_Synchronous::run
0x8c9b8b8 TransportQue::output_lock PlaybackEngine::run
0x8c9bee0 MainIndexes::input_lock MainIndexes::run 1
0x8d8a9f8 RotateEngine::input_lock RotateEngine::run
0x8e48370 (null) (null) *
0x8d078d0 ResourceThread::draw_lock ResourceThread::run
0x8bf0ef8 TransportQue::output_lock PlaybackEngine::run
0x8d35850 BC_Repeater::pause_lock BC_Repeater::run
0x85c0a20 AudioDevice::arm_lock AudioDevice::arm_buffer *
0x85c09e0 AudioDevice::arm_lock AudioDevice::arm_buffer *
0x8a33550 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8b56fc0 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8bf2550 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8d36e58 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8c16490 BC_WindowBase::event_condition BC_WindowBase::get_event
0x8c9dcc8 BC_WindowBase::event_condition BC_WindowBase::get_event
0x85c0a00 AudioDevice::play_lock AudioDevice::run 1 *
0x8e6f8c8 OSSThread::write_lock OSSThread::wait_write
0x85c0a20 AudioDevice::arm_lock AudioDevice::arm_buffer
BC_Signals::dump_buffers: buffer table size=0
BC_Signals::delete_temps: deleting 0 temp files
SigHandler::signal_handler total files=0
Aborted (core dumped)
I loaded this up in gdb and it confirms that it crashed on line (which
appears to validate my suspicion).
My question is why this is happening?
Help please?
thanks
-matt
On 10/28/06, m h <[EMAIL PROTECTED]> wrote:
Ok, simpler test case. Add reverb (concert hall sound effect) to
track and it crashes occasionally when played.
Heres the error:
cinelerra: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
Aborted (core dumped)
The backtrace on the core file says this:
(gdb) bt
#0 0xe410 in __kernel_vsyscall ()
#1 0xb737c129 in raise () from /lib/libc.so.6
#2 0xb737d553 in abort () from /lib/libc.so.6
#3 0xb7375cbd in __assert_fail () from /lib/libc.so.6
#4 0xb74961be in pthread_mutex_lock () from /lib/libpthread.so.0
#5 0xb7a117d9 in Mutex::lock (this=0x8e622d0, location=0x0) at mutex.C:47
#6 0xb24e0bdc in ReverbEngine::run (this=0x8e622b0) at reverb.C:501
#7 0xb7a1ccd9 in Thread::entrypoint (parameters=0x8e622b0) at thread.C:48
#8 0xb7494167 in start_thread () from /lib/libpthread.so.0
#9 0xb740ab7e in clone () from /lib/libc.so.6
Line 501 of reverb.C is this:
input_lock.lock();
I guess I need to read up on pthread locking.
Anyway, can anyone help out here? Does this crash happen for other people?
Should I file another bug for this?
I'd like to help out and start understanding what's going on and
solving some of the crashes that I run into. But I'm at a loss right
now.
-matt
On 10/28/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> http://bugs.cinelerra.org/show_bug.cgi?id=347
>
> --- Additional Comments From [EMAIL PROTECTED] 2006-10-29 00:02 ---
> Here's backtrace info from the core dump:
>
> (gdb) bt
> #0 0xe410 in
Re: [CinCVS] [Bug 347] Crash on with title and reverb effects
Ok, simpler test case. Add reverb (concert hall sound effect) to track and it crashes occasionally when played. Heres the error: cinelerra: pthread_mutex_lock.c:80: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. Aborted (core dumped) The backtrace on the core file says this: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb737c129 in raise () from /lib/libc.so.6 #2 0xb737d553 in abort () from /lib/libc.so.6 #3 0xb7375cbd in __assert_fail () from /lib/libc.so.6 #4 0xb74961be in pthread_mutex_lock () from /lib/libpthread.so.0 #5 0xb7a117d9 in Mutex::lock (this=0x8e622d0, location=0x0) at mutex.C:47 #6 0xb24e0bdc in ReverbEngine::run (this=0x8e622b0) at reverb.C:501 #7 0xb7a1ccd9 in Thread::entrypoint (parameters=0x8e622b0) at thread.C:48 #8 0xb7494167 in start_thread () from /lib/libpthread.so.0 #9 0xb740ab7e in clone () from /lib/libc.so.6 Line 501 of reverb.C is this: input_lock.lock(); I guess I need to read up on pthread locking. Anyway, can anyone help out here? Does this crash happen for other people? Should I file another bug for this? I'd like to help out and start understanding what's going on and solving some of the crashes that I run into. But I'm at a loss right now. -matt On 10/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: http://bugs.cinelerra.org/show_bug.cgi?id=347 --- Additional Comments From [EMAIL PROTECTED] 2006-10-29 00:02 --- Here's backtrace info from the core dump: (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7395129 in raise () from /lib/libc.so.6 #2 0xb7396553 in abort () from /lib/libc.so.6 #3 0xb7a03d94 in signal_entry (signum=11) at bcsignals.C:182 #4 #5 0xb24f9e44 in ReverbEngine::run (this=0x8e63ce8) at reverb.C:505 #6 0xb7a35cd9 in Thread::entrypoint (parameters=0x8e63ce8) at thread.C:48 #7 0xb74ad167 in start_thread () from /lib/libpthread.so.0 #8 0xb7423b7e in clone () from /lib/libc.so.6 Line 505 looks like this (in reverb.C): for(i = 0; i < plugin->total_in_buffers; i++) I'm not familiar with the flow of the code but, I can only find one place where total_in_buffers is set on the plugin. If anyone can shed some light on how to fix this I'd be very happy. thanks --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ 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] Klocwork results
Cinelerra people- I now have a bit of time in the coming week (and motiviation to create a new video since my 3rd child was just born). (The joys of paternity leave) My plan is to try and use the latest merge source (will be working on gentoo). Start making a simple video and whenever I hit a crash, try to figure out what caused it. I'll compile with debug options and run valgrind as well when necessary. If anyone has hints or suggestions that might be handy feel free to share them. Otherwise I'll be popsting my comments/questions here. Hopefully the klockwork results will still be somewhat relevant to the latest source. If others are interesting in the klocwork results, please let me know. I don't think that klocwork would mind me sharing their results as long as you credit them for any fix done using their analysis. I've got a speadsheet export that is probably easier to use than their web interface. -matt ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Initial klocwork report
Folks- Klocwork has run their tool on Cinelerra and provided some initial feedback.When I get some time, I'll start poking through the results in the code. I'm assumming that people feel that the Unititialized Data and Security Vulnerabilites reported below are the (uninteresting) ones to ignore? (ie stuff that won't get patched upstream). -matt Here is their report verbatim: Hope you're having a good week. Sorry about the delay in getting back to you. It took me some time to build cinelerra. Also, our tool uncovered a significant amount of potential defects, so I took some time to go through the results. I have built the trunk which I retrieved on August 18. Here's a summary of the results: -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. 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. 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'. -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. -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. As you can see there are a lot of potential defects; however I am certain that you will find some interesting bugs. We appreciate any feedback concerning patterns of false positives as this will allow us to filter them out in future builds of cinelerra. I've attached a short .pdf presentation that walks through how to use our Project Central interface. Note: since we've only run one build, to see the defects you'll only need to select 'New' state, along with a status of 'Analyze.' These defects will only then be slotted into the 'Existing' state after any future builds. You can go through and inspect them using the web interface and I recommend the following status convention: (1) Real Bugs -> put in 'Fix' (or 'Fix in Next Release') (2) False Reports -> place in 'Not a Problem' (3) Technically correct, by you're not interested/concerned -> place in 'Filter' (this way you won't see them again in future builds) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Valgrind makes cinelerra more stable!
I started messing around with valgrind last night. (It actually makes cinelerra more stable, though unbearably slow). One of my crashes (putting more than one concert hall effects on the audio) crashes cinelerra, but not while running under valgrind. When I get some time, I'll post the results, I need some help to debug this. Also, there appear to be lots of leaks that valgrind is reporting (this is gentoo cinelerra cvs 2.0). Has anyone made any attempt to deal with valgrind? I figure if I'm going to be doing klocwork, coverity stuff, valgrind is up that alley too. I guess I need to learn about pthreads and refresh on my c++. -matt ___ 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 8/17/06, Johannes Sixt <[EMAIL PROTECTED]> wrote: 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. Ok, I've responded to klocwork. I told them I'm not a developer, but that I have their stamp of approval. We'll see what they come back and say. -matt ___ 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 8/16/06, Andraž Tori <[EMAIL PROTECTED]> wrote: On Wed, 2006-08-16 at 21:20 +0200, Johannes Sixt wrote: > 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. actually there might be some off-by-one errors and missing null-pointer checks that can be found using these tools and are worthwhile to fix. however they will probably drown in an ocean of 'uninteresting' bugs... this could indeed be a problem Should do I have the support of maintainers to proceed with klockwork, given that I only fix (submit patches) the "interesting" bugs? ___ 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..
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). 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
[CinCVS] Re: More suggestions from [l]users who don't contribute..
Looks like klocwork has a similar offer open to open source projects: http://www.klocwork.com/company/releases/06_26_06.asp On 7/31/06, m h <[EMAIL PROTECTED]> wrote: Hey Guys- It's been more than a year since I played with Cinelerra. (I've edited a few family movies using cinelerrra. Editing a few hours of dv and a 3 minute movie that was a slide show of pictures. (Lots of panning and zooming)). I would call myself a newbie that is somewhat comfortable with some of the non-intuitive features of Cinelerra. Yesterday my daughter and I were reading the 3 little pigs and we decided to re-inact it for a digital camera (mjpeg). I'm running Gentoo, and this is my first time using the 2.0 series. I had a few issues: * Hanging on adding a title * Rendering to dv failing. * Clipping mjpeg didn't seem to work So in the same vein of users contributing suggestions (like they know better than the devs), I like to ask that you submit the code to be scanned for "bugs" by coverity. http://scan.coverity.com/ Perhaps their scanning tool can find some hard to find bugs that lead to crashes. It's worth attempting isn't it? thanks for your hard work. (Hope my attempt at sarcasm isn't lost...) I really like the potential that cinelerra has, but the crashes are quite annoying. matt ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] More suggestions from [l]users who don't contribute..
Hey Guys- It's been more than a year since I played with Cinelerra. (I've edited a few family movies using cinelerrra. Editing a few hours of dv and a 3 minute movie that was a slide show of pictures. (Lots of panning and zooming)). I would call myself a newbie that is somewhat comfortable with some of the non-intuitive features of Cinelerra. Yesterday my daughter and I were reading the 3 little pigs and we decided to re-inact it for a digital camera (mjpeg). I'm running Gentoo, and this is my first time using the 2.0 series. I had a few issues: * Hanging on adding a title * Rendering to dv failing. * Clipping mjpeg didn't seem to work So in the same vein of users contributing suggestions (like they know better than the devs), I like to ask that you submit the code to be scanned for "bugs" by coverity. http://scan.coverity.com/ Perhaps their scanning tool can find some hard to find bugs that lead to crashes. It's worth attempting isn't it? thanks for your hard work. (Hope my attempt at sarcasm isn't lost...) I really like the potential that cinelerra has, but the crashes are quite annoying. matt ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Creating move from still images
I've been messing around with pyvnc2swf to create a screencast of a vnc session. Using this tool I can export the frames as bmps (if I export as png, cinelerra (and others like gimp) don't recognize the pngs) and convert the bmp's to pngs using imagemagick. Pyvnc2swf grabs at 12fps. Whats the best way to get this at 29fps (for ntsc)? I didn't see this in the wiki anywhere. thanks matt ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
