Re: [Cin] can we push 0009-fileexr-forward-port-openexr-3.patch early?
Checked into GIT. Tested on 32-bit Debian 9.1 just to be sure and includes the following: 0009-fileexr-forward-port-openexr-3.patch 0016-freebsd-in-file.C.patch 0014-freebsd-defines-in-guicast-bcresources.C.patch 0016-freebsd-in-file.C.patch 0017-freebsd-in-dvdcreate.C.patch 0019-disable-frei0r-and-libvmaf-for-freebsd-13-dynamic-ff.patch On Wed, May 4, 2022 at 10:28 AM Andrew Randrianasulu < randrianas...@gmail.com> wrote: > It needed on NetBSD (i need one more patch rel. to netbsd.patch I made > earlier, but I hope to check it first on Freebsd..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] megapile 12 (freebsd, ffmpeg 5, dynamic build, opencv trim)
thanks! On Wednesday, May 4, 2022, Phyllis Smith wrote: > Checked into GIT from the current Megapile, the following: > > 0004-mem-and-resource-leaks-in-indexfile-indextate-cppche.patch > 0005-cppcheck-in-cursor.C.patch > 0006-cppcheck-in-resourcepixmap.C.patch > 0007-Add-objrem-target-for-thirdparty-Makefile-removes-on.patch > 0008-Freebsd-13-conditional-include-in-exportedl.C.patch > 0011-unsigned-long-cast-for-freebsd-in-bctrace.C.patch > 0012-dirent64-and-readdir64-aliases-for-freebsd-in-guicas.patch > 0013-freebsd-includes-in-plugins-titler.patch > 0015-freebsd-in-indexfile.C.patch > 0042-Limit-git-clone-depth-to-1-faster-download-less-spac.patch > > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] megapile 12 (freebsd, ffmpeg 5, dynamic build, opencv trim)
Checked into GIT from the current Megapile, the following: 0004-mem-and-resource-leaks-in-indexfile-indextate-cppche.patch 0005-cppcheck-in-cursor.C.patch 0006-cppcheck-in-resourcepixmap.C.patch 0007-Add-objrem-target-for-thirdparty-Makefile-removes-on.patch 0008-Freebsd-13-conditional-include-in-exportedl.C.patch 0011-unsigned-long-cast-for-freebsd-in-bctrace.C.patch 0012-dirent64-and-readdir64-aliases-for-freebsd-in-guicas.patch 0013-freebsd-includes-in-plugins-titler.patch 0015-freebsd-in-indexfile.C.patch 0042-Limit-git-clone-depth-to-1-faster-download-less-spac.patch -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] can we push 0009-fileexr-forward-port-openexr-3.patch early?
I think I only added two new patches - one workarounding thd encode having ghost 0ch stream and second adding netbsd-specific ifdefs.. if things work for you as-is - hopefully with time and testing pile will shrink) PS: you can look into disabling jasper for opencv On Wednesday, May 4, 2022, Andrea paz wrote: > Can you tell me which patches to remove and which to add from megapile_12? > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] can we push 0009-fileexr-forward-port-openexr-3.patch early?
Can you tell me which patches to remove and which to add from megapile_12? -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] can we push 0009-fileexr-forward-port-openexr-3.patch early?
On Wednesday, May 4, 2022, Phyllis Smith wrote: > Tough call -- I really need to check this out and understand it better. > But if someone else can, I would appreciate the help. > I will finish what I am currently testing - 0004, 0015, 0005-0008, > 0011-0013, 0042 - which should not take much longer and then look at 0009 > again. > thanks! it should be the same as first part of https://github.com/manuvi/cinelerra/commit/fd18893b07b943b175664549b26ad6865751d48d just replacing openexr specific types with standard one... should be compatible with both openexr2 and 3 (for our use-case) > On Wed, May 4, 2022 at 10:28 AM Andrew Randrianasulu < > randrianas...@gmail.com> wrote: > >> It needed on NetBSD (i need one more patch rel. to netbsd.patch I made >> earlier, but I hope to check it first on Freebsd..) > > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] can we push 0009-fileexr-forward-port-openexr-3.patch early?
Tough call -- I really need to check this out and understand it better. But if someone else can, I would appreciate the help. I will finish what I am currently testing - 0004, 0015, 0005-0008, 0011-0013, 0042 - which should not take much longer and then look at 0009 again. On Wed, May 4, 2022 at 10:28 AM Andrew Randrianasulu < randrianas...@gmail.com> wrote: > It needed on NetBSD (i need one more patch rel. to netbsd.patch I made > earlier, but I hope to check it first on Freebsd..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
[Cin] can we push 0009-fileexr-forward-port-openexr-3.patch early?
It needed on NetBSD (i need one more patch rel. to netbsd.patch I made earlier, but I hope to check it first on Freebsd..) -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
Yes, it is helpful to put some more details in the manual. I'll look into it, but let me run a few more tests so I have a clearer idea. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
Andrea, still it would be useful to make a note in the Manual so I will do that unless you would rather do that yourself? It seems to run in reverse more consistently for me and not as jerky - although my test only had 1 video effect added. I have to scale back my enthusiasm. With Further Testing I don't get > much of a boost, especially if there are effects and transitions. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] PreRoll in Cin Digest, Vol 43, Issue 13,
Interesting and quite helpful. Thanks. > While I have not tested the current state of the git repository, I thought > I might add a few comments about testing performance in general from the > perspective of a retired systems programmer. I am a fan of Cinelerra-GG and > use it for burning bluray disks so I hope to be able to test the new code > before long. > It will be interesting to hear your results of burning bluray disks -- especially if you have good speakers where you might be able to differentiate audio options of LPCM and tsMuxer results as I could not. > ... > Any settings within a given application, eg cache or pre-roll, will need > to be measured in a controlled environment which means rebooting the > computer to clear the file system file cache. Otherwise, any request for > data that has been previously read may be satisfied from the operating > systems file cache regardless of the settings in the application. > Measuring this in a controlled environment is very useful to a programmer to improve the code if possible. The problem is for a user, there is no such thing as a controlled environment and just how they "feel" is all that matters. So the best that can be done is for programmers to take advantage of the methods you outline. I do think that the "preroll" of 1.0 seconds as opposed to 0.5 seconds seems more consistent for me as a user -- it made me "feel" better! > ... > It goes without saying that any use of swap space will radically degrade > performance unless that swap space is on a solid state drive and the swap > partition is quite generous in size. > I gave up on swap space years ago -- if you have to swap, you may as well reboot. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] PreRoll in Cin Digest, Vol 43, Issue 13,
On Wednesday, May 4, 2022, Andrea paz via Cin wrote: > Thank you for the valuable information. I attach the result of > heaptrack done with the system already started for 1-2 hours and with > the system just rebooted (...cin.1185) > [https://www.dropbox.com/s/kko33qk3gvnyni9/heaptrack.cin..tar.gz?dl=0]. > I used a 28s video (h264) with 3 transitions. I simply started > playback and when I reached the end of the track, I started reverse > playback. I used Cache size=8192 and Preroll=2.0s. I attach an image > of the heaptrack graph and the link to the files obtained from > heaptrack. I'm not very good at interpreting them, except the attached > graph which clearly shows the transitions problem. I have a PC with > 32GB of Ram and a swap file of 4GB (I only need it to avoid problems > with hibernation/suspension). > > - Do you recommend increasing my swap file? > - From the heaptrack results of my test, do you see any memory issues? > And if so, can they be fixed? > - Do you have any suggestions on how to fluidify CinGG playback, > especially with effects and transitions? > well, canonical suggestion is to use background rendering over selected region, I think? but in general you can try to add '-march=native' and other machine-specific cflags in adiition to -Ofast in cinelerra/Makefile (Ofast applied to our scaler functions). Also, time back Bill changed caching algo so it worked without crashing in 32-bit mode. May be we can conditionally revert those changes for 64-bit compile... -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Seconds to preroll render
Thanks. I have to scale back my enthusiasm. With Further Testing I don't get much of a boost, especially if there are effects and transitions. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] PreRoll in Cin Digest, Vol 43, Issue 13,
Phyllis et al, While I have not tested the current state of the git repository, I thought I might add a few comments about testing performance in general from the perspective of a retired systems programmer. I am a fan of Cinelerra-GG and use it for burning bluray disks so I hope to be able to test the new code before long. I realize that the posts to which I am referring are not intended as exhaustive, definitive test suites, but it can be useful to know how the results can be affected. On most operating systems, memory requested by an application is not returned to the system wide free pool when the application releases it with a call to free or delete. You can see this by running a memory intensive application in one window and the gnome-system-monitor (or equivalent) in another window. Unless there is a great deal of demand for free memory by other applications, this memory will remain assigned to the first application until that application is closed. Therefore, each test should be run from a fresh invocation of the test application. Unfortunately, this doesn't guarantee that the file system cache is flushed. Any settings within a given application, eg cache or pre-roll, will need to be measured in a controlled environment which means rebooting the computer to clear the file system file cache. Otherwise, any request for data that has been previously read may be satisfied from the operating systems file cache regardless of the settings in the application. That said, the effect of the file system cache loading will be most or exclusively felt in short tests that fit completely or mostly within the file system cache. The tests should be run with as few other applications loaded as possible to minimize CPU contention and disk access. If there is a way to run the test from the command line, this will eliminate additional video card specific rendering issues, by which I mean presenting the images on the screen. I am not referring to using GPU's used to render the video to the files on disk that will be read during playback. Of course, if what you are trying to measure is the onscreen presentation rate, then a command line test is not appropriate. The terminal commands free and top can be used to see how much memory is being allocated to caches. If you run these before and after a test, you should see an increase in the memory allocated to the file caches. You can use the command: cat /proc/meminfo to see how much memory is being allocated to file system caches. Note: these values are for an older laptop with only 8 GB of physical ram and an 8 GB physical swap partition. cat /proc/meminfo MemTotal: 7802112 kB MemFree: 2199052 kB MemAvailable: 5405988 kB Buffers: 175436 kB Cached: 3361856 kB SwapCached: 0 kB Active: 1470940 kB Inactive: 3556264 kB Active(anon): 4204 kB Inactive(anon): 1616348 kB Active(file): 1466736 kB Inactive(file): 1939916 kB swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 7.9G 0B -2 /dev/zram0 partition 7.4G 0B 100 See the URL below for a description of the zram0 swap partition. https://www.kernel.org/doc/html/v5.3/admin-guide/blockdev/zram.html It goes without saying that any use of swap space will radically degrade performance unless that swap space is on a solid state drive and the swap partition is quite generous in size. Recent versions of Fedora, ie 33 and newer, seem to favor a compressed swap space and/or using memory compression, which can have a large impact on memory intensive operations. My recommendation is to use a dedicated, on disk (SSD) swap partition that is twice the size of physical memory or larger depending on the memory requirements of your application. I use the Fotoxx graphics application to make very large panoramas and have frequently used up to 40 GB of swap space on a system with 16 GB of physical ram. Cinerlerra is nowhere near that memory hungry, but it is essential to avoid running into situations where the kernel will have to evict code pages or data from the cache. The output of the swapon command indicates that the compressed zram0 block device has a much higher priority than the physical disk based swap partition. This can negatively impact file caching if your on disk swap partition is fast and your memory is older, slower memory. It may be worth trying to limit the size of