- Cin - Cinelerra-GG Mailing Lists

Video Transitions not locking into track?
by Stefan de Konink 27 Jan '22

27 Jan '22

I am using a recent git version of Cinelerra, and I notice that I cannot drop a video transition between two pasted clips anymore. So I do see the white square as placement, but the icon after it does not follow. Neither is the transition visually applied between the two clips. (I have also seen the case where the icon isn't there, but the transition happens, but not today.) -- Stefan

3 5

Ligature rendering in the title effect
by Stefan de Konink 26 Jan '22

26 Jan '22

Within Cinelerra the Title effect does not seem to have the same result for the same font. The rendering backend within Inkscape gives ligatures and cursive connections of the Parisienne in an ideal way. Cinelerra does not join the letters. The font used; <https://fonts.google.com/specimen/Parisienne> The individual renderings, notice the broken connection between the 'a' and 'n'. -- Stefan

3 9

Again bugs in alignment
by Stefan de Konink 24 Jan '22

24 Jan '22

In the attached screenshot you can visually see where the original cut has to start at 00.720, while it appears at the rendered version at a little more than 0.200. Yes, I had to introduce this silence to prevent the audio being cut off from the beginning. The source material of this project can be made available in full. -- Stefan

4 9

Re: [Cin] Crash on playback
by Phyllis Smith 21 Jan '22

21 Jan '22

Mark, > > It does not crash when using X11 OpenGL, only X11. X11 with direct render > does not seem to be faster when using vdpau, so I think I have a workable > solution that does not require extra tracks. > Curiouser and curiouser. I checked and I was using X11 and not OpenGL. I have created a multibit AppImage on my Fedora 29 computer(which is an HP/Intel/Broadwell graphics board) and have uploaded it. When I tested this AppImage moved to an AMD Ryzen-7 (with a Radeon graphics board) vdpau worked for me on tutorial.mp4 file. It did not work with DSCF0220.MOV though probably due to limitations of my board. When you have time and the inclination, you should see if it works for you by downloading: https://cinelerra-gg.org/download/testing/cin-x86_older-distros_multibit.Ap…

2 3

Re: [Cin] Crash on playback
by Phyllis Smith 21 Jan '22

21 Jan '22

Mark, > If you get vdpau working, could you build a multibit version appimage for > older systems? That would cover all my use cases. > Yes, that would be easy IF I get vdpau working. > > I shared a sample file. You should be able to download the original file > from this link also: > As expected, no crash while playing on Fedora 29 (with same glibc and kernel version level). Maybe I will try installing RHEL8 out of curiosity). Trying to fix something when I can not reproduce it, is impossible. Also, when booting my old Fedora 29, I noticed there is another partition labeled Fedora 29 - Cuda development so that should prove helpful. > >

1 0

Re: [Cin] Crash on playback
by Phyllis Smith 19 Jan '22

19 Jan '22

Mark, Now that you have found a workaround, I do not know if you want to continue to work on resolving this. If so, don't bother reading the rest of this. Or how much more time to test you want to do. Depending on your goal: ?? do you want to build yourself (if so, I have Fedora 29 on a partition and am compiling my latest CinGG tar there right now to see if I can reproduce the error you are getting. It has the same kernel of 4.18 as RHEL8 and glibc of 2.28 as you mentioned - Fedora 28 is earlier than that). I could also try to download RHEL8 as a developer for free but I don't know how far I would get with that and reproducing the error. ?? OR would you prefer to just use AppImage if vdpau worked? (if so, I can work on trying to figure out a solution because others have the same issue). ?? have you tried this easy test of using the default configuration file to make sure indexes are rebuilt and there is nothing strange in your cinelerra_rc file? ,.e. CIN_CONFIG-/tmp/bcast1 ./bin/cin About: > compiled it. It worked for a while but now it crashes with the following > when I hit the play button. There were some system updates installed in the > interim. > ?? is it possible that the system updates included a technology called pre-linking, which supposedly "speed up a start of a binary which uses dynamically loaded libraries by linking these libraries in advance ("prelinking" the executable file) using the 'relocating' technique. This basically means that each time the binary is run, the shared libraries are loaded to a randomly chosen memory addresses, which may sometimes interfere with the addresses at which the program shared memory segments are to be attached." The reason I ask is because when I look up the error message you first reported of "could not attach shared memory" it talks about this error and a solution as follows: Per the internet, you can disable prelink by editing /etc/sysconfig/prelink (set PRELINKING=no), then run /etc/cron.daily/prelink so the prelinking of the libraries in the system will be disabled. Fedora and Red Hat Enterprise Linux (RHEL) supposedly enable pre-linking by default which means I have been using it that way for years without a known problem. But I do not see a file called /etc/sysconfig/prelink on my Fedora 32. RHEL8 uses glibc 2.28, kind of annoying they stayed there as many newer > things want a later version. They have a habit of backporting things > though, including kernel changes, such that the conditional compile based > on versions sometimes fails and a special case for a Redhat kernel needs to > be added. Who knows if they backported something in glibc? > > >> If I set the compiled version to not use any hardware accel, it still >>> crashes. I don't think the vdpau issue and the crash are related. The crash >>> is my big concern obviously, as any work not saved is lost. >>> >> > Why would it not crash if there is another video on the timeline below > what I am playing? At least that is a workaround. It can be another copy of > the same track. > Good question! > > Thanks for taking up the mantle of the open source Cinelerra gg. I was > very peripherally involved with Cinelerra CV in 2011. I provided a patch > for SOWT audio and communicated with Einar at that time. I see that is now > handled by ffmpeg. > We just want to make sure Cinelerra lives on and stays relevant after all of the hard work you and many, many others have done !

1 0

Colors [was: Crash on playback]
by Andrea paz 18 Jan '22

18 Jan '22

@Andrew > @Andrea, for some reason I can't download attaches from forum (because I have no login there?), can you add CMS.txt as attachment to email (again)? I'm opening a new email because color has nothing to do with the Vdpau/Vaapi issues. It was just an attempt to put together all the information on how CinGG treats color. Lately I found emails from Hermann Vosseler that are very indicative. However, the fact remains that each plugins of CinGG treats the color in its own way, so we should find a way to understand how all the native plugins act, one by one (if I'm not mistaken, the plugins of ffmpeg clip everything to 8-bit and sRGB). Only with this information can we reconstruct a chain of steps that accounts for color transformations and, perhaps, keep them under control. Sorry, I've been pushing too much color lately, it's best to let it go. Hermann already knew in 2012 that it was not possible to treat it in CinCV and that's also why he went for Lumiera.

3 3

nvdec - > va-api wrapper
by Andrew Randrianasulu 18 Jan '22

18 Jan '22

does not support av1 yet, mostly aimed at firefox use (but kodi {mediacenter} also might work) v 0.0.2 https://github.com/elFarto/nvidia-vaapi-driver found via Phoronix

1 0

Crash on playback
by Mark Goldberg 17 Jan '22

17 Jan '22

I have an RHEL8 system and wanted support for vdpau playback. The appimage does not seem to work, dropping back to software playback. I downloaded the Dec 31 2021 tarball and compiled it. It worked for a while but now it crashes with the following when I hit the play button. There were some system updates installed in the interim. VFrame::allocate_data 518 could not attach shared memory, 930x523 (model 6) shmid=0x00000000 shmall = 18446744073692774399 shmmax = 18446744073692774399 shmmni = 4096 shmused = 50173032 (6 items) shmother = 4870728 (8 items) Mutex::lock: Success Mutex::unlock: Invalid argument Regards, Mark

5 10

CFLAGS (was: Re: Crash on playback)
by Andrew Randrianasulu 17 Jan '22

17 Jan '22

cflags I tried some time ago (on 32 bit build but with avx-enabled amd cpu fx-4300, with gcc 5.5.0) https://github.com/Randrianasulu/CinelerraGG-slackbuild/blob/master/cineler… "-O3 -ffast-math -mavx -march=native -mtune=native -fopenmp" not much use for openmp, but if you want some experiments you can try to put some #pragma omp simd" around hot source code blocks and see if it helps... On Monday, January 17, 2022, Andrew Randrianasulu <randrianasulu(a)gmail.com> wrote: > > > On Monday, January 17, 2022, Mark Goldberg via Cin < > cin(a)lists.cinelerra-gg.org> wrote: > >> >> On Mon, Jan 17, 2022, 3:32 AM mat <mnieuw(a)zap.a2000.nl> wrote: >> >>> >>> >>> @Mark, can you confirm vdpau works on your system, outside of CinGG? >>> Does vdpauinfo say it is OK? >>> Does "HW device" vdpau work in the compiled version without errors, >>> apart from the crash? >>> >> >> On RHEL8 the appimage for older distros is required as glibc is older. It >> does not work with vdpau, falling back to software. In the locally compiled >> version it does use vdpau, but I have 4k60 f-log videos, and adding the >> lut3d plugin slows things down such that it cannot play in real time. >> > > > you can try to hack makefiles of individual plugins (while lut3d is > ffmpeg's one, so not sure how to influence irs compile flags individually) > with > -march=native, -mavx (if you have avx instructions in your cpu), and > other suitable flags... CinGG for now mostly cpu/memory intensive, not > using OpenCL/cuda (unlike big commercial editors?) so setting correct cpu > flags may give relatively big boost. > > > >> @Andrew, I have compiled multiple times and changed versions of the >> Nvidia driver, same crash. >> > > from forum post I see case when gpu decoder utilization (as seen via > nvidia's utility) still not 0%, so it works, but probably pulling and > pushing frames between vram and ram via pci-e bus takes cpu, too (even if > dma should do it for free?). I remember long time ago open-source radeon > driver developers run into some underutilization of bus so they applied big > expensive logic analyzer (at pcie speeds!) for finding some bottlenecks.... > so I am afraid without much better developers poking graphics stack while > Cingg is running not much can be done.. :( > > @Andrea, for some reason I can't download attaches from forum (because I > have no login there?), can you add CMS.txt as attachment to email (again)? > > I recall older version of Final Cut (before X) has ColorSync plugin > (probably utilizing cpu at early 2000s), so may be making lcms2 plugin will > provide some workaround for lack of core color management? (like, you > switch slow colorcorrection plugin/effect for color work, turn it off for > edits... those transforms using monitor's profile tend to be math heavy if > executed on cpu only, even with simd... ) > >> >> @Andrea, I have seen the forum posting. There are issues with plugins >> slowing things down, but I will start a second thread for that. >> >> Latest compile is the multibit version. It's more complicated. If there >> is another video track on the timeline below what is playing, it does not >> crash and plays successfully. >> > > sorry, I can't test this due to lack of access to my main desktop... and > laptops here only have vaapi (may be I can recompile x86_32 version of > cingg... those are not *my* laptops, but I have live usb stick with > slackware /copy of my home system from ~2020) > >> >> Regards, >> >> Mark >> >>>

1 0