 |
The logged problem was fixed. I am always concerned about the note 1471 "impression that the image in the composer plays less fluidly than it used to" but maybe more definitive information will arise in the future. |
 |
it's all OK. No booby for me. |
 |
Okay, it works. If I configure X11-OpenGL and simply restart with "cin", then open an xml... Cin-GG does not crash and I can use it. However, with an xml containing 4 mixers, I have the impression that the image in the composer plays less fluidly than it used to. This is the case with both X11-OpenGL and X11, regardless of whether I launch Cin-GG with the "cin" command or with "CIN_FINISH=0./cin". If I try to run Cin-GG with the command "IN_HW_DEV=vdpau./cin", CVin-GG does not start. |
|
|
Pierre: a fix has been generated for Mint 18 and a test build is available: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz Since we were able to reproduce the error here, gg was also able to see that the fix checked into GIT fixes it. Let me know if your results differ. Andrea: CIN_FINISH has been removed. GG expects there might be a booby so watch out for them. |
|
|
First @Andrea - somehow I missed your note the other day, so will look at it today but after today's late breaking relevations it might not be the same problem. Second @Pierre - GG managed to get Mint 18.3 and Nvidia 384.130 installed onto an HP laptop (not the i7 Intel which did not have an Nvidia graphics board). He ran a test Cinelerra "Greatest Show" trailer with no problem and was getting the "Clowns" ready to load and thought he would just go ahead and switch to X11-OpenGL video driver. Guess what? It immediately crashed and the dump shows the exact same problem. Now he can work on it! It has something to do with Mint 18.3 somehow. So there may be no new solution that provides a fix, but at least we will know what it is and can continue with the current workaround. There are other Mint 18.3 users out there and they will have the same problem. |
|
|
I'm writing here because I think it's the same problem as Pierre (even if I don't have crashes; I didn't use multi mixers; I have Nvidia 460M). Start CinGG with CIN_HW_DEV=vdpau and with CIN_FINISH=0. Project 1: 4 sources h264 (.mp4) in a single track. results: no problem; no error in terminal; Playback X11 >> X11-OpenGL Project 2: 7 sources in a track, one clip cloned in a second track .pro - h264(.3gp) - h264 (.mp4) - h264 (.mp4) [cloned] - h264 (.mp4) - h264 (.3gp) - h264 (.3gp) - h264 (.3gp) results: error in terminal; playback X11 = X11-OpenGL [no vdpau playing, for me] I attach a strange photo in displaying the clips; the errors in the terminal and also the .xml files (not the sources because they are very large and I have a very slow connection in uopload).
terminal.txt (2,953 bytes)
vdpau.jpg (113,623 bytes)
test.xml (10,051 bytes)CC-15c.xml (12,844 bytes) |
|
|
Of course, Cin-GG does not come with any guarantee and that is normal. This has not prevented me from carrying out many editing projects thanks to cin for several years. But as during these last tests you insisted to remind me to save my xml (which I will always do anyway), I am a little more precocious in this case... This version works well, I don't see any difference in behavior with the previous one. X11-OpenGL works as agreed but is really not adequate for use with mixers; because the composer is getting too slow. When working with mixers only X11 gives a really usable result. |
|
|
On Mint in the directory where you login, just like there is a .shuttlerc file, there is a .profile file. You would just edit the .profile file and add the line, probably to the bottom: export CIN_FINISH=0 that should be it, then the next time you login it should take effect and you can just key in ./cin to start up cinelerra. |
|
|
As far as safe, it is the same version that is going to be used for the builds tomorrow. Cinelerra has never come with any guarantees! It is generally good form to always back up the XML EDLs but the original media is always safe because it is never modified by Cin. You can just continue using the line: CIN_FINISH=0 ./cin but probably it will become cumbersome after awhile to type this rather than just ./cin. I will have to look up the correct .profile file and get back to you on the correct procedural explanation for Mint. |
|
|
Okay, I'll test the new version, I would need more procedural explanation to understand what I need to do with this: "it is recommended that the following line be added to the $HOME/.profile file: export CIN_FINISH=0" Is the new version safe so that I can continue to work on the two xml that were causing problems? |
|
|
Although this is not a fix, using CIN_FINISH=0 is a workaround that we are going to have to live with until the OpenGL GL-ew fix is done by the appropriate other developers. It is hoped that only a few computer systems will encounter the problem. Since it may be inconvenient to remember to always use this environment variable, it is recommended that the following line be added to the $HOME/.profile file: export CIN_FINISH=0 until such time as the root cause is fixed or an alternative workaround is discovered. And as for the other observations, I am going to try to put all of the anomalies with play speed / jerkiness into a single new issue. A new MINT18 build should be tested. It is at: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz |
|
|
It works Phyllis.... Both problematic xml work without any problems. I have also alternated between X11-OpenGL and X11 on several occasions and without difficulty. However, I notice that every time I play the composer's image, I have a black frame at the beginning that appears, for the duration of a... flash... black. With xml which contains only HDV sources and no mixers, the composer plays at normal speed under X11-OpenGL. On the other hand, with the xml which contains 4 mixers, DNxHD sources and mpeg proxies, the composer is extremely slow (about 1 frame/second) on X11-OpenGL, while the mixers play at a rather normal speed. If I use the Shuttle to vary the composer's speed, he reacts normally, without slowing down. |
|
|
Hi, Pierre: If you have time could you test this workaround for the OpenGL xml failures you were getting: https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-x86_64-static.txz After you load this in order to use it you will have to do in the cinelerra directory: CIN_FINISH=0 ./cin (just like you did for CIN_HW_DEV=vdpau ./bin) Then please test the 2 XML files that were crashing with these with OpenGL. I hope they work now. |
|
|
Not yet, I think your previous tests were pretty conclusive. The error is in Nvidia and there are probably other users who will have the same problem depending on the graphics board and the Nvidia version. GG is going to have to add a flag to get past this. The problem is a result of drawing the camera, projector, and safe regions green, red, yellow and white "overlays" after playing stops. He preferred the code to run the way it was previously but some complaints arose when the overlay lines did not get redrawn until the user stepped forward 1 frame and then back 1 frame. |
|
|
Phyllis, Would you like me to reinstall the April 25 version of "cinelerra-5.1-mint18-x86_64_64-static.txz 2019-04-25 19:35", to confirm that it really causes a problem with X11-OpenGL ? |
|
|
Now.... I installed libva-dev, libvdpau-dev and cinelerra-5.1-mint18-pierre-x86_64-static.txz. I started Cin-GG with the command "CIN_HW_DEV=vdpau./cin". X11-OpenGL works and I can switch with X11 without any problems. With my xml which contains 4 mixers and under X11-OpenGL the display of the composer is extremely slow. The mixers play at normal speed. Under X11, the composer displays at normal speed... and even, surprisingly... the display in the composer of DNxHD sources seems even more fluid than with mpeg proxies. |
|
|
Yes, I mean libva-dev and libvdpau. I was wrong earlier and edited this -- You can use the Pierre version with no problems so you will be able to test CIN_HW_DEV if desirable. More later as there is ongoing discussion between me and GG. |
|
|
Sorry to have taken so long to answer you, I was taken with other things this afternoon. My old .bcast5 works and I can switch from X11 to X11-OpenGL without any problems. My xml project which contains 4 mixers works under X11-OpenGL and all 4 mixers play at normal speed. On the other hand, the composer's image scrolls extremely slowly under OpenGL, whether with source media in DHxHD or with Proxys in mpeg. Under X11 the composer's image scrolls at normal speed. I would now be ready to follow your instructions but, vaapi and vdpau does not exist under that exact name in Synaptic, do you mean libva-dev and libvdpau-dev or is that something else? Then I could replace cinelerra-5.1-mint18.2-20190331.x86_64-static.txz with the version you just prepared. I await your indications for vaapi and vdpau... |
|
|
AND you must already have BOTH libraries for vaapi and vdpau installed or CinGG will not even start. |
|
|
Pierre: when you have time, please try the following but be sure to backup whichever XML file you use it on. It will let us know if the "finish_output" mod is affecting opengl but does not fix anything. Be forewarned that overlays for camera and projector will not work correctly because that is what the finish_output mod was to fix. Thanks in advance. https://www.cinelerra-gg.org/download/testing/cinelerra-5.1-mint18-pierre-x86_64-static.txz |
|
|
Pierre: I am going through the timing here as obviously everything was OK on March 31 (BTW - thanks for going the extra mile in narrowing down this issue). There was a mod created with respect to the camera and projector for overlays on April 10 in the playback 3d routine that affects OpenGL. A test Mint18 was created on April 20th which would have included that mod and then on April 24th a fix for "fix draw_refresh opengl deadlock" was checked in but this last fix should have been ncluded in the Mint 18.2 April 25 build. It is not clear that this is what is causing the problem, but later today GG will create a Mint18 build that does not include the "finish_output" mod and have you test that. So I do not know if you want to wait for that instead of re-testing the latest version of CinGG or not. Either way it will narrow down what is causing the problem but since we can not reproduce it here, gg will not know how to resolve it. |
|
|
Okay good development...... I deleted the contents of the directory containing my CinGG installation, as well as .bcast5. I have installed cinelerra-5.1-mint18.2-20190331.x86_64-static.txz OpenGL now works... I can open correctly the .xml that caused a CinGG to crash. I will then try to put back my old.bcast5, if all goes well, I will put back the latest version of CinGG and re-install libva-dev and libvdpau-dev (which I had removed). We'll see if this time everything will remain stable... |
|
|
I should have been more specific.... I had specifically installed the Nvidia driver by the Linux Mint Driver Manager, as recommended under this distribution. |
 |
As far as I understand it, the OpenGL libraries of Nvidia must be installed in any case, so that you can use OpenGL. It is not enough to install only standard drivers from Nvidia. You should also have VDPAU installed so that you can use the hardware acceleration if you have Nvidia graphics card. It seems to me that Cinelerra is trying to access these libraries and can't execute the commands correctly. The problem is probably the missing libraries. Maybe my tip will help you. |
|
|
When I use the X11 CinGG video driver, it doesn't crash. The current Nvidia drivers is the one installed and updated automatically by Linux Mint 18.3. I have no difficulty opening his configuration tool. CinGG does not crash on X11, but once I have configured X11-OpenGL, the next launch of CinGG does not even complete itself. |
|
|
The dumps are all showing the same results. Some questions and more work for you: - does it crash when you use X11 instead? - gg suggests that you install the latest Nvidia drivers or reinstall to make sure everything is in sync with your O/S - this probably will not help, but send me privately the XML file (not the source video files) just so we can take a look at it\ - also, does it crash immediately or do some files show in the Resources window? |
|
|
I renamed".bcast5" to cause it to be replaced by a fresh one. I launched CinGG and chose X11-OpenGL. I restarted CinGG and it crashed immediately, even before I could load an.xml. pierre@i7-3770k ~ $ /home/pierre/Cinelerra-GG_5.1/cin Cinelerra Infinity - built: Apr 25 2019 10:16:02 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2018 Heroine Virtual Ltd. by Adam Williams (c) 2007-2018 cin5 derivative by W.P. Morrow aka goodguy 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. ** segv at 0x7ff77b5fdc29 in pid 11660, tid 11702 writing debug data to /tmp/cinelerra_11660.dmp lock_items: 20 lock_frees: 3 ** dump complete Erreur de segmentation (core dumped) pierre@i7-3770k ~ $ cinelerra_11660.dmp (58,278 bytes) |
|
|
Same problem cinelerra_11056.dmp (93,203 bytes) |
|
|
That is a possibility --you could try deleting the indexes which you can easily do from Settings->Preferences, Interface tab, "Delete existing indexes". Do this before loading the project. Be aware that this means when you load files again, it will take slightly longer as new indexes have to be created for each file. |
|
|
Could the cause be found in a corruption of an item in my".bcast5" directory? |
|
|
I don't think this problem is caused by vdpau and vaapi. I first observed it a few days ago (before I installed vdpau and vaapi), I didn't report it right away, because I thought it was just a temporary aberration... but it's rather my logic that often suffers from permanent aberration... |
|
|
I tested about 25 previous XML files - simple cases and none very old with the result of no crashes. At least 2 had MIXERS but the rest were all without MIXERS. Used vdpau and X11-OpenGL. GG looked at the dump and ascertained that for some reason OpenGL started to execute constant data in the data area instead of program code at 7f93c59c1000 as in: 7f93c58f6000-7f93c59c1000 r-xp 00000000 08:15 402190 /usr/lib/nvidia-384/libGL.so.384.130 7f93c59c1000-7f93c59f5000 rwxp 000cb000 08:15 402190 /usr/lib/nvidia-384/libGL.so.384.130 We got nothing - no cause, no solution, just worry about potential problems with vdpau and vaapi. |
|
|
Thanks for the dmp file. GG is looking at it now and will see if he can find any cause. I will test some old xml files myself. |
|
|
cinelerra_5242.dmp (92,901 bytes) |
- Anonymous
