I read in QuickStart.pdf that the mkv format is not perfectly compatible with CinGG. As a further contribution I can say that every time I use mkv format (with any codec) it always comes out in the terminal the string: "FFMPEG::open_decoder: some stream times estimated: /home/paz/video_editing/prova/MyVideo.mkv" In these cases the file management, both in playback and rendering, is much heavier. For example, a rendering of two mkv files (x264) of about 1 Gb in total takes more than an hour, while similar mp4 files (x264) take 25 minutes. Is there anything I can do about it? I would love to be able to use containers and codecs associated with mkv. Have others had similar experiences?
Andrea, I did a little bit of experimentation with mkv this morning and can at least pass along some observations.
every time I use mkv format (with any codec) it always comes out in the terminal the string: "FFMPEG::open_decoder: some stream times estimated: /home/paz/video_editing/prova/MyVideo.mkv"
This does not cause any real problems. Basically, when you open a file, if a stream has a known duration, there is no message. It really should have a duration but it often obviously does not. If the duration is unknown, it is estimated by: using File Size and Bitrate to estimate the duration anyway, the stream number cinelerra uses versus ffmpeg for mkv may be counted differently (per gg).
In these cases the file management, both in playback and rendering, is much heavier. For example, a rendering of two mkv files (x264) of about 1 Gb in total takes more than an hour, while similar mp4 files (x264) take 25 minutes.
In my experience, if you look at the size of the files generated, the mkv file is a lot smaller so I believe that that is why it is so heavy on the CPU usage and takes twice as long to generate. I do not see much difference when I increase the number of "threads" used or modify the "speed" parameter. AV1 files have this same small size / slow render issue. Is there anything I can do about it? I would
love to be able to use containers and codecs associated with mkv. Have others had similar experiences?
The only thing I have been able to do to speed up the rendering to take less time is *modify "crf" to a higher number* - allowable values range from 0-63 and the cin-gg opts files have it set to 32 which is considered a good setting to use. When you click on the wrench in the video render menu, you see crf=32 and you can change it there. I could not tell if the quality difference of using crf=45 (which is supposed to be of lower quality and runs faster) is detrimental or not. It really looked the same to me but I used a low resolution video. And the time savings helps but it still slower than using mp4. You have probably already looked at the following URL, but that is what Frederic Roentz referred to often: https://developers.google.com/media/vp9/settings/vod/
This does not cause any real problems. Basically, when you open a file, if a stream has a known duration, there is no message. It really should have a duration but it often obviously does not.
Yes, we have already discussed this and I know that the message is not one of error. But every time it appears I have problems; with mp4 and webm the message never appears and the rendering is always fast. In addition I can say that with mkv it seems to me that cinGG exploits a core, with mp4 exploits them all. To be precise with mkv the 8 threads range from 0% to 75%, while with mp4 they range from 40% to 100%. (seen with the KDE system monitor; I don't know how significant it is). Note that using ffmpeg from the command line does not show any slowdowns (but the settings of cfr or other may be different; I don't know). Last but not least, it's a stupid consideration, because it shows my ignorance of these issues: Adam Williams in the 7.1 introduced corrections regarding mkvs (although for quicktime and not ffmpeg). Could it not be that Cin (not only CinGG) has an internal problem, not of the engine it uses, that can decrease efficiency?
To be precise with mkv the 8 threads range from 0% to 75%, while with mp4 they range from 40% to 100%. (seen with the KDE system monitor; I don't know how significant it is). Note that using ffmpeg from the command line does not show any slowdowns (but the settings of cfr or other may be different; I don't know).
The above is helpful information that gg is going to be interested in investigating further. Why such a big difference in cpu usage? --- he will want to see if he can figure that out!
Adam Williams in the 7.1 introduced corrections regarding mkvs (although for quicktime and not ffmpeg). Could it not be that Cin (not only CinGG) has an internal problem, not of the engine it uses, that can decrease efficiency?
From the comments below in filemkv.C from version 7.1 of Adam's, I do not think it is a lack in CinGG, but rather MKV. GG is going to have to look at it as it is way beyond me.
// NOT USED
// an attempt to get frame accurate seeking with MKV, which ended up // showing MKV doesn't have the required information in the 1st place.
I
Adam Williams in the 7.1 introduced corrections regarding mkvs (although for quicktime and not ffmpeg). Could it not be that Cin (not only CinGG) has an internal problem, not of the engine it uses, that can decrease efficiency?
As was the case a long time ago, probably the problems are with my system (PC or Arch, I don't know) and not with CinGG. Yesterday also the problems with ProRes files started; today also with mp4 files. I decided to reinstall CinGG but I can't do it anymore. I tried it three times manually and once with build.sh. The build always stops at the same point. I have no problems with overheating, Smart controls do not detect errors on the SSD. It could be some new Arch Linux update, but I don't know what: I don't find any problem reports. I attach two cin5.log, but one would be enough because they look the same to me. https://www.dropbox.com/s/dmqwrh095g1pjkw/plugin.zip?dl=0 (do not mind the name of the zip, it is to recycle the dropbox link)
Andrea, Thanks for sending the log file -- gg was able to spot the build error right away from that. It is a problem with all of the libraries that we updated to get an early start on this month's builds for the general pubic BUT so far only with Arch. Of course it worked for us on Fedora and that was the only 1 we tested. He has *checked in a fix *that disables the TIFF library attempt of the thirdparty build of "zstd" - zstd was trying to build test files from the Tiff library. It is a common thing to do but as you can see created a problem. He did a build on a default Arch system here with the fix in and it worked. When you have time, please attempt another build using the latest GIT repository. And as always, *we appreciate* the fact that you do the build from the source so we get extra eyes and help with this effort and we apologize for the inconvenience. GG/Phyllis The build always stops at the same point.
It could be some new Arch Linux update, but I don't
know what: I don't find any problem reports.
Even if I managed to install CinGG, the playback problems remain. With mkv the problem is more serious but the other containers don't work well anymore. Watch the video: https://www.dropbox.com/s/hf3hd80dqja08jz/playback.mp4?dl=0 There is a first slowdown at the first wipe transition, then slowly the playback resumes fluidity. At the second transition the insertion point slows down a lot, so much so that it seems blocked, while the audio continues to flow normally. This happens to me every effect or transition I put on, and it gets worse using mkv (with any codec below) which slows down even simple playback without effects. I don't know when this problem started, but no less than a month. I don't even know if it's due to my PC. Surely it had never occurred before. Notebook i7 2720QM; Geforce 460M, 12 GB RAM, SSD; Checked "Play Every Frame"; Video-driver: X11-OpenGL;
Andrea: There is a first slowdown at the first wipe transition, then slowly
the playback resumes fluidity. At the second transition the insertion point slows down a lot, so much so that it seems blocked, while the audio continues to flow normally. ... I don't know when this problem started, but no less than a month. I don't even know if it's due to my PC. Surely it had never occurred before.
It is not obvious what the problem is. I watched your video and can see it slow down, but I can not create the same situation here. I ran a couple of tests using yesterday's build versus December 30, 2018 build with 10+ transitions at the edits and do not see any problems. Attached shows the tracks with the transitions in it that I played over and over and timed using: time ./cin Results were as follows: Build date - *12/30/2018* Test 1 Test 2 Session time: 0:01:54 Session time: 0:01:48 real 1m54.902s real 1m48.314s *user 0m59.660s user 0m59.383s* sys 0m5.677s sys 0m5.601s Build date - *02/04/2019* Test 1 Test 2 Session time: 0:01:52 Session time: 0:01:48 real 1m52.613s real 1m47.953s *user 0m59.356s user 0m59.005s* sys 0m5.511s sys 0m5.662s I am going to try a more complicated test yet and compare. Phyllis
I am going to try a more complicated test yet and compare. Phyllis
No Phyllis, please don't waste your time on further testing. The problem is so big and obvious that there would have been so many reports. So it's obvious that it's a problem with my system alone. If I can get to grips with it, I'll let you know.
Andrea, I guess that you are editing at 1080p (@29.97fps ?) and your source videos are at 1080p. I can not compare your powerful i7 Notebook with my poor DualCore Notebook, but I noticed that, when I use transitions, it is better, on my system,to set Video driver on X11 and "use direct x11 render if possible" in Preferences. Have you tryed, just for testing? IgorBeg
Use 1080p and 30fps smartphone movies, or capture video (vokoscreen) under the same conditions. Using the video driver as X11 (use direct X11 render if possible) slightly improves the situation compared to X11-openGL. But the real difference is that it disables "Play every frame" (as Pierre has also noticed). All other settings in the "Playback A*" tab have no effect at all. However, the situation gets worse and worse, now slows down even without transitions or effects, just go from one edit to the next to get a block and then resume normally. In the meantime I made a backup of my system, because I see it ugly for the future.
A question: playback in CinGG (in X11-OpenGL or X11) use GPU or only CPU? Il giorno mer 6 feb 2019 alle ore 10:53 Andrea paz <[email protected]> ha scritto:
Use 1080p and 30fps smartphone movies, or capture video (vokoscreen) under the same conditions. Using the video driver as X11 (use direct X11 render if possible) slightly improves the situation compared to X11-openGL. But the real difference is that it disables "Play every frame" (as Pierre has also noticed). All other settings in the "Playback A*" tab have no effect at all. However, the situation gets worse and worse, now slows down even without transitions or effects, just go from one edit to the next to get a block and then resume normally. In the meantime I made a backup of my system, because I see it ugly for the future.
I think I have a similar or related issue, but on another hardware. My XPS 13 with i7-8550U CPU and Intel UHD Graphics 620 (Kabylake GT2) has the following drivers installed on Leap 15: intel-vaapi-driver | Intel Driver for Video Acceleration (VA) API-> libvulkan_intel | Mesa vulkan driver for Intel GPU xf86-video-intel | Intel video driver for the Xorg X server On this platform I can load and play UHD_H265 video (recorded on a Pixel3 phone) both with the Totem and the Dragon players. Cinx won't load or playback this video, so therefore I thought Cinelerra didn't use hardware acclelerated video GPU, maybe I'm wrong? In comparision on another Skylake i7/Nvidia machine, none of these video players or VLC is able to playback this video. As mentioned by Phyllis/GG it appears that this UHD video file is single-threaded. A workaround is to preprocess the file first with ffmeg before loading it in Cinelerra. Terje J. H Den 06.02.2019 10:56, skrev Andrea paz: A question: playback in CinGG (in X11-OpenGL or X11) use GPU or only CPU?: Il giorno mer 6 feb 2019 alle ore 10:53 Andrea paz <[email protected]><mailto:[email protected]> ha scritto: Use 1080p and 30fps smartphone movies, or capture video (vokoscreen) under the same conditions. Using the video driver as X11 (use direct X11 render if possible) slightly improves the situation compared to X11-openGL. But the real difference is that it disables "Play every frame" (as Pierre has also noticed). All other settings in the "Playback A*" tab have no effect at all. However, the situation gets worse and worse, now slows down even without transitions or effects, just go from one edit to the next to get a block and then resume normally. In the meantime I made a backup of my system, because I see it ugly for the future.
The new build slightly improves the situation but does not solve it completely. See the attached video. https://streamable.com/vwuhu Finally I had slowdowns even without effects/transitions, it was enough to go from one edit to the next. Now this second case is solved. If you need tests, logs, valgrind or anything, let me know.
My test/work with Cinelerra are always with Proxy enabled (generally without Scaler) and mpeg or mov codec for "fast" editing on my very old Notebook. Then I don't know if what I am writing may have sense for you. OS: UbuntuStudio_16.04 Project: [email protected] fps. Source video: mp4, [email protected] Proxy Settings: 1/3 (640x360), mpeg, 1800000bps. Settings: Play every frame= checked Timeline shows: abcd|12345|ABCD Two transitions 2sec length: Dissolve and Slide. Cin_Ub16-20181231-static 1) X11-OpenGL: Framerate achieved MIN= 25.4 2) X11 (use direct x11 render if possible): Framerate achieved MIN= 29.3 Cin_Ub16-20190206-static-testing 1) X11-OpenGL: Framerate achieved MIN= 24.7 2) X11 (use direct x11 render if possible): Framerate achieved MIN= 28.5 I think that mpeg file (by Proxy)) help a lot my poor Notebook because video resolution is reduced by 1/3 but also GOP=11. In the source video GOP=90. Then I guess that the ffmpeg/Cin engine have work less with more i-frames. What do you think about? Thanks. IgorBeg Note: The Framerate achieved MIN is the value minimum read in the Setting during three plays
Andrea: Forgive my ignorance, how do you get the FPS?
If you are referring to the fps in IgorB's statement: Source video: mp4, [email protected] The easiest way I have found to find that is to go to the Resources window, click on the Media folder, highlight the video you want to know about, and then right mouse on the video and then choose "Info". It shows Video "Frame rate". Hopefully that number is the one you want to see in Settings->Preferences, Playback A tab in the Frame rate achieved number. Phyllis
No, I refer to the framerate of the playback (I think): "Framerate achieved MIN= 28.5"
You see "Framerate achieved" followed by a number (yes the playback) when you use the Settings pulldown and choose Preferences. Then click on the Playback A tab in the Video section, next to the checkbox for "Play every frame". If you leave the preferences window up,while you are playing, you can see the Framerate achieved go up and down. No, I refer to the framerate of the playback (I think):
"Framerate achieved MIN= 28.5"
Andrea, sorry for the late. Phyllis said to you well where I see the value of "Framerate achieved". Thanks. For info, what is the GOP value of your source video? It would be intersting to know. To make video editing at 1080p in a powerful PC with i7 CPU should fly, I think. Thanks IgorBeg
For info, what is the GOP value of your source video? It would be intersting to know.
The attached image shows the grabshot of CinGG info. Which program can I use to view GOPs? https://i.postimg.cc/PJrVm6Jp/grab.jpg
Which program can I use to view GOPs? Thanks for your info, Andrea. Surely I am not helping you about the native thread "MKV containers", then I am sorry.
Time ago I found "getgop.sh" script by Dan Dennedy. I added a compressed file. Inside, you find the script and my "readme" for the info (too many things to remember, then I usually write a lot of readme files). Maybe there are others programs like "Mediainfo", more user friendly, but I don't know if the GOP value is calculated by them. IgorBeg
What I know, to NLEs don't like great value GOP because the I-frame are very distance. I-frames (Intra frames) contains all the information of the image, P-frames (Predicted frames) and B-frames (Bidirectional predicted frames) not. Greater GOP value is, smaller file size is (it is good for streaming and delivery); smaller GOP value is, greater file size is and more I-frames there are and then it is good for editing video. With more i-frames cpu consumes less because decode less information. For video archive would be better GOP=1 (all i-frames) Sorry, I guess, you always know that. However, you have a i7 cpu with a lot of RAM, then your PC should process your video very good, I think. Have you tried to use Proxy with scale value to 1/2, just for testing? If Proxy with "mpeg" you do, the GOP value is 12, then could be very useful. (I think, I am writing like Joda Jedi speak) ;-) IgorBeg Il 08/02/2019 23.41, Andrea paz ha scritto:
Thanks for the script. Max GOP = 250
I attach a video: the first part is made with an mpeg proxy (I have not seen its GOP), then there are examples without proxy with X11 and with X11.opengl. The file consists of screen capture with vokoscreen and gave rise to mp4 files with GOP but at 250. With proxy I am fixed at 30 fps, in the other cases we speak of very low fps. @IgorBeg. Thanks for the info. Very clear and informative. If you talk like Yoda, then I talk like Chewbacca. :-) @Phyllis. Could you tell me which libraries have been updated lately? So I can do a search in the Arch linux forum/wiki to see if they are causing any problems. https://www.dropbox.com/s/z3na1r3vmwcnn6n/test.webm?dl=0
Andrea:
If you talk like Yoda, then I talk like Chewbacca. :-)
I hope I do not talk like Jar Jar Binks ! But sometimes my responses sound that way to me ! @Phyllis. Could you tell me which libraries have been updated lately?
So I can do a search in the Arch linux forum/wiki to see if they are causing any problems.
That would be helpful as GG has already had some problems with libtool needed for WebP (Suse) and it would be good to know ahead of the end of the month builds, if there are other library problems with any of the other distros. x265 version 3.0 fftw-3.3.8 libogg-1.3.3 libvorbis-1.3.6 openjpeg-2.3.0 opus-1.3 tiff-4.0.10 + https://github.com/webmproject/libwebp = libwebp-1.0.2 (needs libtool, not sure which version) https://github.com/mozilla/aom = libaom-v1.0.0 Thanks for your help and I am quite behind in things lately so if I miss something that needs immediate attention, just yell louder in your best Yoda or Chewbacca voice. gg/phyllis
Andrea, Your video is very illustrative. I know nothing about GOP except that when working on bluray media, it was necessary to include gop in the opts files. I attach a video: the first part is made with an mpeg proxy (I have
not seen its GOP), then there are examples without proxy with X11 and with X11.opengl. The file consists of screen capture with vokoscreen and gave rise to mp4 files with GOP but at 250. With proxy I am fixed at 30 fps, in the other cases we speak of very low fps.
I made a *background rendering video *but what I am trying to show is explained below url: https://streamable.com/g9v1d What I am attempting to demonstrate in the video is when you playback and get to a transition slow point, the framerate achieved is only 20 instead of the expected 30. However, if you use background rendering, then it will stay at 30 framerate because it only has to re-rendering during playback the frames that have been changed. When you do background rendering, what it does is render each frame individually so you will end up with potentially hundreds of single files in /tmp called brender0001, brender0002, .... Since these are usually JPEG files, you can view them too and swap one out (I think but never tried this.) Page 21 of the old cinelerra manual discusses this too.
@Andrea Thanks for your video. It explain very well the different cases. If it don't waste your time and if you have time, you could transcode your source video (1080p) to mpeg and re-test in the same condition. So we (all) can see how i7-cpu "digests" the mpeg codec. I can not to do that because my pc is too much poor (usually I set Proxy scale to 1/4 for projects at 1080p). Yes, It still doesn't help to solve the problem. Unfortunately I am not an expert in ffmpeg (like olaf or igor_ubuntu, and others), I just copy and paste after reading, but if you want to transcode your file with ffmpeg in the command line: ffmpeg -i inputvideo.mp4 -c:v mpeg2video -q:v 2 -c:a copy outputvideo.mpg @Phyllis I saw your video. I learned another thing about Cinelerra, even if my old Notebook is really poor. Thanks! @Terje Thanks to you I can see that Mediainfo shows the GOP value. And I see that the mobile phones have all great GOP value to compress the file (my phone records with GOP=90). Thanks! IgorBeg PS: Who has the Millennium falcon, please? ;-P
Some time ago I tried to use the background rendering to get the list of png images. Now, using it on a test movie doesn't seem to affect achivied frames (which always remain 14 fps dropping to 4 fps with plugins). But the most disconcerting thing is that you do not create still images: the folder I had indicated remains empty, even in /tmp I can't find anything. In short, background rendering doesn't seem to work on my system (as if that wasn't enough!). I've tried both to enable the render farm in localhost and to disable it. Same result. On the arch forum I don't find any problem with the graphic libraries, the versions are the same. The only thing that comes to mind is a formatting of the notebook and restart from 0. But I'll wait until after finishing the translations for the website.
Just the time to chimp in... Intro: Hello, I'm new here, and am still evaluating Cinelerra to see if I can work with it. I'm an event videographer. I come from Windows/Vegas pro, and my main goal in this regard is to ditch windows, and am looking for program. Cinelerra looks to me the most mature on Linux, but it seems to "speak an exotic language" to me. So prepare to a lot of newbie stupid questions from me in the near future. (Still trying things before bothering you...) And now my chimp in: Videos created with phones often are not just simply long GOP, but are also variable frame rate. If something, that can screw up timeline to my experience - not sure about Cinelerra though. Just my 2 cents. Thank you for your attention Laszlo Kovacs P.S: My kids are StarWars fans... ;) 2019. 02. 10. 12:30 keltezéssel, Igor BEGHETTO írta:
@Andrea Thanks for your video. It explain very well the different cases. If it don't waste your time and if you have time, you could transcode your source video (1080p) to mpeg and re-test in the same condition. So we (all) can see how i7-cpu "digests" the mpeg codec. I can not to do that because my pc is too much poor (usually I set Proxy scale to 1/4 for projects at 1080p). Yes, It still doesn't help to solve the problem. Unfortunately I am not an expert in ffmpeg (like olaf or igor_ubuntu, and others), I just copy and paste after reading, but if you want to transcode your file with ffmpeg in the command line: ffmpeg -i inputvideo.mp4 -c:v mpeg2video -q:v 2 -c:a copy outputvideo.mpg
@Phyllis I saw your video. I learned another thing about Cinelerra, even if my old Notebook is really poor. Thanks!
@Terje Thanks to you I can see that Mediainfo shows the GOP value. And I see that the mobile phones have all great GOP value to compress the file (my phone records with GOP=90). Thanks!
IgorBeg
PS: Who has the Millennium falcon, please? ;-P
Laszlo: Cinelerra ... seems to "speak an exotic language" to me.
So prepare to a lot of newbie stupid questions from me in the near future. (Still trying things before bothering you...)
Welcome to Cinelerra! Ask any newbie questions you want. A lot of us are still newbie too and even if not newbie, everyone seems to do things differently. I am would be *very interested* to see if cinelerra can handle "Videos created with phones often are not just simply long GOP, but are also variable frame rate. If something, that can screw up timeline to my experience". I think that will not be a problem, but *I would like to know* so gg can look at it if it is. GG/Phyllis
To deal with Cin's different operating philosophy compared to other editors, the first hurdle is to understand that it works on the tracks in their entirety and not on individual edits. Recently, "fast drag" has been introduced to make it more similar (and comfortable) to other editors. But it remains the basic concept of enabling and disabling tracks according to the need of the moment. "Shift + click" on the arm button in the patchbay, enables the track disarming all others.
For my problem: I found in the arch wiki: "When is patching acceptable? It's inevitable that some software will need modifications to work. Patches to the *build system* are pretty much always allowed. This is usually needed when Arch's tools are too new for shipped scripts, and things do not work right (libtool is a known offender here)." But I don't understand what it means. Is it important for my problems? Can libtool be the problem? More test. I found a program: "Namcap is a tool to check binary packages and source PKGBUILDs for common packaging mistakes, which can also be automatically enabled." I tried to run it with cin...pkg.tar.xz for arch. I enclose the result. Towards the end of the file there are some errors, but I can not judge if they have to do with my problem.
As already mentioned, GOP values can be found also with Mediainfo. Here some extracted samples among my video files: Pixel-3 recorded: mediainfo HD_H264_VID_20181218_131437.mp4 | grep GOP Format settings, GOP : M=1, N=60 mediainfo hdv01.m2t | grep GOP Format settings, GOP : M=3, N=12 mediainfo SD-BD_x264.m2ts | grep GOP Format settings, GOP : M=4, N=24 mediainfo HDV-BD_m2t_ac3.m2ts | grep GOP Format settings, GOP : M=3, N=12 Possibly slow playback can be related to old Cinelerra GOP issues, i.e. among these posts on the old list? https://www.mail-archive.com/search?l=cinelerra%40skolelinux.no&q=gop&x=0&y=... Terje Den 09.02.2019 11:39, skrev Igor BEGHETTO: What I know, to NLEs don't like great value GOP because the I-frame are very distance. I-frames (Intra frames) contains all the information of the image, P-frames (Predicted frames) and B-frames (Bidirectional predicted frames) not. Greater GOP value is, smaller file size is (it is good for streaming and delivery); smaller GOP value is, greater file size is and more I-frames there are and then it is good for editing video. With more i-frames cpu consumes less because decode less information. For video archive would be better GOP=1 (all i-frames) Sorry, I guess, you always know that. However, you have a i7 cpu with a lot of RAM, then your PC should process your video very good, I think. Have you tried to use Proxy with scale value to 1/2, just for testing? If Proxy with "mpeg" you do, the GOP value is 12, then could be very useful. (I think, I am writing like Joda Jedi speak) ;-) IgorBeg Il 08/02/2019 23.41, Andrea paz ha scritto: Thanks for the script. Max GOP = 250 Meldingsteksten vil bli nedlastet etter behov.
Andrea:
problem is so big and obvious that there would have been so many reports. So it's obvious that it's a problem with my system alone.
Maybe, but not necessarily! You built from the GIT repository which has some BIG changes in that were not in the January 31 build which almost everyone else is using. There are 6 library updates AND the deadlock problem that gg fixed impacted a lot of routines. So it is not a waste of time for me to test anyway, because I have to have something more interesting to aim for and am in the process of trying to get a "single frame" failure that Pierre incurs too (issue #125). Also, I will try to get GG to build a ubuntu16 version later today so IgorB can verify that this newest version does not slow down - which will help isolate the problem to just your computer. Unfortunately for IgorB, the drag handles have not been modified to more closely fit his expectations because GG thinks that the consistency of how they work and are coded is too important to change, but I am still working on it/him! OpenGL is used in playback when it can, but not always. If a plugin or transition has code of "handle OpenGL", it usually will use that, but not all plugins/transitions do, which means it will use software rendering instead and be slow. The demo you emailed earlier where the sound continues to play but the video stops shows the problem that occurs when the program is short of CPU -- this is where "Play every frame" can be turned off to help. Also, it does not look like you have "colors" enabled and that is good -- having to draw the colors is time-consuming (but apparently "Charlie" can handle it). Background rendering, which I think is misnamed, may be a good way handle larger media and I am trying to understand it better and will put a demo out later if I can. Glen MacArthur uses it a lot on one of his slower computers. You have to be sure to set it up in settings->preferences, Interface tab, and especially create the background rendering directory because it creates many, many brender files - one for each frame. gg/phyllis
participants (5)
-
Andrea paz -
Igor BEGHETTO -
Kovács László -
Phyllis Smith -
Terje J Hanssen