Re: [CinCVS] General Cinelerra performance
Dennis Schulmeister wrote: I wonder if there are any optimizations I could do to improve performance There's no single optimization that we can recommend that will certainly solve your problem. On my system I had a performance problem that turned out to be an audio setup problem (Playback of dv material went from 5fps to 30fps just by muting the audio output!). If you have the time, try using OProfile or some other profiler to find out what part of cinelerra is eating all that CPU. -Brendan ([EMAIL PROTECTED]) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] General Cinelerra performance
Hello, Generally speaking this is what I get: * Playback of one half size PAL video track with mono sound: ~50% / ~60% CPU utilization. * Playback of a full size PAL video track with stereo sound: ~90% / 100% CPU utilization. That's not unreasonable for a 2GHz cpu, depending on the codec. What codec is your input video using? I've never found cinelerra to be the fastest viewer. It's strength is in editing and rendering the result. The full size track is a MPEG2 file with AC3 Audio. The other one is some quicktime file from the Internet. OpenGL only helps with effects display (and possibly frame resize, but I haven't heard that officially.) If you already see slow performance, I'd run without OpenGL unless you are trying to view an effect that OpenGL supports. I might turn it on just to test if viewing the segment was faster with OpenGL though. OpenGL also helps with playback but if enabled neither real-time effects nor transitions are shown. I wonder what's the cause for that. Of course I don't intend to use Cinelerra as some media player. :) But I wonder if I will be able to do any serious work with it if even a single PAL track is so resource demanding. From other NLE video software I'm used to if the system can't do the processing in real-time it'll render low-res preview files before giving a preview. Ulead's MediaStudio is even as clever as to only rerender the changed parts. I wonder if there's a similar feature in Cinelerra. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schliffkopfweg 12 - 76189 Karlsruhe - Germany Tel: 0721/5978883 - Fax: 0721/5705992 - [EMAIL PROTECTED] http://www.windows3.de - http://www.denchris.de http://www.audiominds.com - http://www.motagator.net/bands/65 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] General Cinelerra performance
Hi Hermann, thank you for your answer. Frankly, Cinelerra is not that sort of program I would show a newbee to impress him how brilliant open source is. No need to impress me. So far I'm quite pleased with Cinerlerra's feature set. Actually I like the idea of proxy editing. But imho it should be possible to do editing of a full-size PAL project without proxy files. Since the project files are plain xml-files it should be possible to hack together a python script which remote controls Cinelerra in order to create and play some preview files. Hopefully when I got some time by next weekend I'd love to have a look on that. its main strengthes beeing rather in the video/compositing engine and not in the GUI. In fact I like the GUI quite a lot. (Except for those big Ok and Cancel buttons). It's a lot like MediaStudio which I used to use on Windows for ten years. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schliffkopfweg 12 - 76189 Karlsruhe - Germany Tel: 0721/5978883 - Fax: 0721/5705992 - [EMAIL PROTECTED] http://www.windows3.de - http://www.denchris.de http://www.audiominds.com - http://www.motagator.net/bands/65 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] General Cinelerra performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis Schulmeister schrieb: Since the project files are plain xml-files it should be possible to hack together a python script which remote controls Cinelerra in order to create and play some preview files. Hopefully when I got some time by next weekend I'd love to have a look on that. Maybe you could improve our script At the moment it just changes the reference, but it could automatically create new entries for the proxy media in the media folder. But another problem at the moment is that cinelerra doesn't close several xml tags correctly (I started to make a patch to fix this and did't find the time to test it)... In fact I like the GUI quite a lot. (Except for those big Ok and Cancel buttons). It's a lot like MediaStudio which I used to use on Windows for ten years. I often found it tedious to work with, if the project gets larger and more elaborate. It has some fine key shortcuts though. Another problem is the hand-written GUI toolkit (libguicast), which just doesn't performe as smoothly and fast as -- say gtk or qt or even java/swing. Greetings, Hermann V. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGM5JUZbZrB6HelLIRAn4EAKDT1KqccEAxQgRdDesDYEf+1u7RjwCgoMGQ gpm6RNtD0PkvRKr8bWlKf4A= =lI4I -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] General Cinelerra performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis Schulmeister schrieb: Another problem is the hand-written GUI toolkit (libguicast), which just doesn't perform as smoothly and fast as -- say gtk or qt or even java/swing. I already wondered which toolkit is used. I don't like java/swing that much because it's absolutely not my taste. But I fell absolutely in love with GTK. Unfortunately the community version focuses very much on source compatibility to heroine's version. I'm sure rewriting the GUI to use GTK instead would bring some benefits regarding stability. for sure, but -- at the time cinelerra was started, there were not so much viable alternatives, esp. for writing such an rather complicated gui. So the aproach just write ourselfs what we need seems quite reasonable. The GIMP people did exactly the same (and hence we have GTK)... The focus on source compatibiliy to heroine's version is quite understandable. Cinelerra seriousely is lacking developer man power. The single largest code contributions still stem from HV. Changing this situation and trying to switch to GTK would require quite some committment by several people. Even given enough manpower, such a project could easily require a year in order to catch up and deliver something comparable in terms of completeness with the current cinelerra. Hermann V. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGM7H2ZbZrB6HelLIRAlhLAJ9SHP7EX6uJhsch/L/I//xjpAKd8ACgnDy1 8mrkkOWl/1CnahADB/e7Y40= =SS1p -END PGP SIGNATURE- ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] General Cinelerra performance
Ichthyostega wrote: Dennis Schulmeister schrieb: Another problem is the hand-written GUI toolkit (libguicast), which just doesn't perform as smoothly and fast as -- say gtk or qt or even java/swing. I already wondered which toolkit is used. I don't like java/swing that much because it's absolutely not my taste. But I fell absolutely in love with GTK. libguicast originates from the time when other toolkits wheren't available/fast enough (around 1996). I profiled certain things and its true that in some respects things could be optimized and I'll working on that. But generally guicast is a layer above the xlibs which doesnt perform that bad. In far future (maybe 1-2 years) I might like to transist cinelerra to GTK+. This would be a *very* big task and I certainly won't do this alone. When it is time we can bring up this topic again and negotiate with HV about such a change. But for now there are IMO really more important things to do (stabilization, std libs, some design refactoring). There are some good reasons that the CV version follows HV closely and don't want to loose mergability with it. To loosen this requirement I started my branch where a I am already done some mildly intrusive changes and working on it without too much care for HV mergability (while I would like to keep it somewhat mergeable with the CV version). I would really like if people who are serioulsy interested in contributing new features to cinelerra join my efforts and help me on my branch. As far as possible i'll try to bring fixes and good things back into mainline CV (which won't always be possible). There is a Wiki Page where I describe the things which I am working on: http://www.pipapo.org/pipawiki/Cinelerra/Developers/ct/CinelerraEnhanced Christian (I'll be 4 days out of office until wednesday, don't expect responses) ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] General Cinelerra performance
Hi, Like I told in my first message I'm trying to run Cinelerra 2.1CV on a 2 GHz, 1GiB RAM IA-32 AthlonXP Machine on Ubuntu 7.04 real-time. Now I wanted to ask for general opinion what performance I can expect. Although there are working binary drivers with proper OpenGL support for my NVIDIA card installed Cinelerra performs quite poor. While using the OpenGL output driver helps a little bit it introduces its very own problems. It will playback video but without any applied real-time effect and without any transition. Note that this driver also has video problems say with GStreamer applications. So I'm falling back to X11-XV output which will show effects and transitions but with even poorer performance. Generally speaking this is what I get: * Playback of one half size PAL video track with mono sound: ~50% / ~60% CPU utilization. * Playback of a full size PAL video track with stereo sound: ~90% / 100% CPU utilization. We're talking about playback of a single dry video track with one or two dry audio tracks. No effects, nothing. When using the OpenGL driver you could subtract about 10%. Turning background rendering on makes things even worse. CPU utilization will remain at 100% during playback. So this is no option. I wonder if there are any optimizations I could do to improve performance. Thank you. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schliffkopfweg 12 - 76189 Karlsruhe - Germany Tel: 0721/5978883 - Fax: 0721/5705992 - [EMAIL PROTECTED] http://www.windows3.de - http://www.denchris.de http://www.audiominds.com - http://www.motagator.net/bands/65 ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] General Cinelerra performance
On 2007-04-27 22:10, Dennis Schulmeister wrote: Hi, Like I told in my first message I'm trying to run Cinelerra 2.1CV on a 2 GHz, 1GiB RAM IA-32 AthlonXP Machine on Ubuntu 7.04 real-time. Now I wanted to ask for general opinion what performance I can expect. Although there are working binary drivers with proper OpenGL support for my NVIDIA card installed Cinelerra performs quite poor. While using the OpenGL output driver helps a little bit it introduces its very own problems. It will playback video but without any applied real-time effect and without any transition. Note that this driver also has video problems say with GStreamer applications. So I'm falling back to X11-XV output which will show effects and transitions but with even poorer performance. Generally speaking this is what I get: * Playback of one half size PAL video track with mono sound: ~50% / ~60% CPU utilization. * Playback of a full size PAL video track with stereo sound: ~90% / 100% CPU utilization. That's not unreasonable for a 2GHz cpu, depending on the codec. What codec is your input video using? I've never found cinelerra to be the fastest viewer. It's strength is in editing and rendering the result. We're talking about playback of a single dry video track with one or two dry audio tracks. No effects, nothing. When using the OpenGL driver you could subtract about 10%. OpenGL only helps with effects display (and possibly frame resize, but I haven't heard that officially.) If you already see slow performance, I'd run without OpenGL unless you are trying to view an effect that OpenGL supports. I might turn it on just to test if viewing the segment was faster with OpenGL though. -- Kevin ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
