Re: [Cin] Cingg bg render crash video scenario
пт, 1 сент. 2023 г., 04:28 Phyllis Smith : > OK, and is this WITHOUT the fix in? > yes, I have rebuild Slackware pkg from git, installed it -> no more crash! > > On Thu, Aug 31, 2023 at 5:51 PM Andrew Randrianasulu < > randrianas...@gmail.com> wrote: > >> https://youtu.be/URnvDY7Zjic >> >> at least cin does this on my 32-bit-on-64-bit kernel system ... >> >> recorded by another instance of the same cin version. >> >> Note, my machine set to full 3.97 Ghz speed. Also, I have 4 frames per >> bg job setting >> > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Cingg bg render crash video scenario
OK, and is this WITHOUT the fix in? On Thu, Aug 31, 2023 at 5:51 PM Andrew Randrianasulu < randrianas...@gmail.com> wrote: > https://youtu.be/URnvDY7Zjic > > at least cin does this on my 32-bit-on-64-bit kernel system ... > > recorded by another instance of the same cin version. > > Note, my machine set to full 3.97 Ghz speed. Also, I have 4 frames per > bg job setting > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
[Cin] Cingg bg render crash video scenario
https://youtu.be/URnvDY7Zjic at least cin does this on my 32-bit-on-64-bit kernel system ... recorded by another instance of the same cin version. Note, my machine set to full 3.97 Ghz speed. Also, I have 4 frames per bg job setting -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
On Fri, Sep 1, 2023 at 1:59 AM Andrew Randrianasulu wrote: > > > > пт, 1 сент. 2023 г., 01:27 Phyllis Smith : >> >> Just FYI: >> My comprehension of this bug with Background Rendering change of file format >> is still missing mostly due to lack of time yesterday, but I will follow the >> discussion and try to understand it. Thank goodness Andrea was able to >> follow it and verify the error/fix. But I did fix my local copy of the >> Release Notes to correctly state: >>> >>> Reading error handling bug for background rendering in fileexr.C when do an >>> on-the-fly compressor >>> >>> switch has been fixed. >> >> Today, using the previous GIT, like Andrea, I have not gotten any crashes >> yet. >> >> However, it may be that changing this background rendering File Format >> requires the same type of restart of CinGG as when you change your >> Appearance of the Theme from Cakewalk to SUV or whatever. Maybe that would >> be preferable to "Try/Catch" in only fileexr.C?? > > > Well, it seems some deeper layer of rendering stack in cinelerra does not > check (if we change type of image file in bg render dialog without stopping > said bg render) type of file by signature and just feed incorrect file to all > native image read functions, not just openexr. > > So, I guess some "programmatically disable/enable bg render if preferences > for it change" might be good idea, along with user reporting (gui message) of > unwritable/nonexisting directory there and may be button to remove prev bg > render data like we can remove indexes manually. > > But this is bigger change, I yet to try to implement those ideas... > > I was worrying about openexr behavior too, esp if used with external library, > but this case seems to work fine, too at least on Slackware 15.0 i586. > > I do not think we should worry about this mechanism too much - it was around > since long time, and in this case library itself throwning exception, so I > guess we supposed to catch it in our code! Also, I tried 64-bit Rosa 2016 (gcc 5.5.0, glibc 2.24) build and it works ... Thing is, my initial testing was with brender files on tmpfs (/dev/shm), so may be try to put brender files there and see how it goes? (yes, /tmp in modern distros often mounted to /dev/shm anyway, but in my case it is not and I prefer to keep it this way. > >> >> On Thu, Aug 31, 2023 at 1:31 AM Andrea paz >> wrote: >>> >>> > Thanks! Did you try yesterday's scenario with bg render set to jpeg, >>> > enabled, then set to any other compression / filetype, and re-enabled via >>> > menu so you have red bar at top of topmost video track but at this point >>> > it made from wrong image type so prev. version of file reading routines >>> > were crashing? if you position playhead there? >>> >>> I don't quite understand the problem. >>> 1- No crash, but I don't know if I've done the steps you described >>> correctly. >>> 2- Creating a BRender in jpg, then disabling the BG. Going into >>> Preference and changing the BR from jpg sequence to EXR (and PNG) >>> sequence, creating a new BRender, I still have the jpeg sequence >>> active and no sequences were created with the other formats. >>> 3- Closed and restarted CinGG; created new BRender in tga: all OK. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
пт, 1 сент. 2023 г., 01:27 Phyllis Smith : > Just FYI: > My comprehension of this bug with Background Rendering change of file > format is still missing mostly due to lack of time yesterday, but I will > follow the discussion and try to understand it. Thank goodness Andrea was > able to follow it and verify the error/fix. But I did fix my local copy of > the Release Notes to correctly state: > >> Reading error handling bug for *background rendering* in fileexr.C when >> do an on-the-fly compressor >> >> switch has been fixed. >> > Today, using the previous GIT, like Andrea, I have not gotten any crashes > yet. > > However, it may be that changing this background rendering File Format > requires the same type of restart of CinGG as when you change your > Appearance of the Theme from Cakewalk to SUV or whatever. Maybe that > would be preferable to "Try/Catch" in only fileexr.C?? > Well, it seems some deeper layer of rendering stack in cinelerra does not check (if we change type of image file in bg render dialog without stopping said bg render) type of file by signature and just feed incorrect file to all native image read functions, not just openexr. So, I guess some "programmatically disable/enable bg render if preferences for it change" might be good idea, along with user reporting (gui message) of unwritable/nonexisting directory there and may be button to remove prev bg render data like we can remove indexes manually. But this is bigger change, I yet to try to implement those ideas... I was worrying about openexr behavior too, esp if used with external library, but this case seems to work fine, too at least on Slackware 15.0 i586. I do not think we should worry about this mechanism too much - it was around since long time, and in this case library itself throwning exception, so I guess we supposed to catch it in our code! > On Thu, Aug 31, 2023 at 1:31 AM Andrea paz > wrote: > >> > Thanks! Did you try yesterday's scenario with bg render set to jpeg, >> enabled, then set to any other compression / filetype, and re-enabled via >> menu so you have red bar at top of topmost video track but at this point it >> made from wrong image type so prev. version of file reading routines were >> crashing? if you position playhead there? >> >> I don't quite understand the problem. >> 1- No crash, but I don't know if I've done the steps you described >> correctly. >> 2- Creating a BRender in jpg, then disabling the BG. Going into >> Preference and changing the BR from jpg sequence to EXR (and PNG) >> sequence, creating a new BRender, I still have the jpeg sequence >> active and no sequences were created with the other formats. >> 3- Closed and restarted CinGG; created new BRender in tga: all OK. >> > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
Just FYI: My comprehension of this bug with Background Rendering change of file format is still missing mostly due to lack of time yesterday, but I will follow the discussion and try to understand it. Thank goodness Andrea was able to follow it and verify the error/fix. But I did fix my local copy of the Release Notes to correctly state: > Reading error handling bug for *background rendering* in fileexr.C when > do an on-the-fly compressor > > switch has been fixed. > Today, using the previous GIT, like Andrea, I have not gotten any crashes yet. However, it may be that changing this background rendering File Format requires the same type of restart of CinGG as when you change your Appearance of the Theme from Cakewalk to SUV or whatever. Maybe that would be preferable to "Try/Catch" in only fileexr.C?? On Thu, Aug 31, 2023 at 1:31 AM Andrea paz wrote: > > Thanks! Did you try yesterday's scenario with bg render set to jpeg, > enabled, then set to any other compression / filetype, and re-enabled via > menu so you have red bar at top of topmost video track but at this point it > made from wrong image type so prev. version of file reading routines were > crashing? if you position playhead there? > > I don't quite understand the problem. > 1- No crash, but I don't know if I've done the steps you described > correctly. > 2- Creating a BRender in jpg, then disabling the BG. Going into > Preference and changing the BR from jpg sequence to EXR (and PNG) > sequence, creating a new BRender, I still have the jpeg sequence > active and no sequences were created with the other formats. > 3- Closed and restarted CinGG; created new BRender in tga: all OK. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
пт, 1 сент. 2023 г., 00:23 Phyllis Smith : > Catching up on email now. > > with shared 4.4 rebuild I got crash due to new ffmpeg filters I >> enabled, so I added them to blocklist in ffmpeg/plugins.opts >> >> Andrew, in case you did not notice, I checked in the plugin.opts file you > had attached with the commented out azmq and zmq. Not sure where these 2 > came from as they do not appear to be in the current 5.1 ffmpeg plugins > that show up in the Resources window although I do see them in > ffmpeg-5.1/libavfilter/allfilters.c. > They just disabled by default in ffmpeg configuration. I enabled them for local ffmpeg 4.4 builds just for seeing if they will work - not come around for testing yet ( I think vapoursynth uses same libraries, for some remote control? so I had them installed at some point) Not sure how that all works anyway. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
Catching up on email now. with shared 4.4 rebuild I got crash due to new ffmpeg filters I > enabled, so I added them to blocklist in ffmpeg/plugins.opts > > Andrew, in case you did not notice, I checked in the plugin.opts file you had attached with the commented out azmq and zmq. Not sure where these 2 came from as they do not appear to be in the current 5.1 ffmpeg plugins that show up in the Resources window although I do see them in ffmpeg-5.1/libavfilter/allfilters.c. Not sure how that all works anyway. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Monthly AppImage updates
чт, 31 авг. 2023 г., 23:26 Phyllis Smith via Cin : > Despite the potential for problems, late checkin of changes, and not too > much testing, a new set of AppImages is now available for download. As > always, if problems, simply revert to the previous AppImage. Changes > includedare listed below. > ** > *Mirror* is a new user contributed new video plugin and has been > documented in the Manual. > *Gain *audio plugin has been improved to include the text box for precise > designation of the gain and the clear/reset button to revert to the > default. This was a user contribution. > > *Andrew contributions include:* > The *About* in the Settings→Preferences now shows the Copyright to > include the Cinelerra-GG team, the previous Cinelerra-CV team, as well as > the libav version. This is also shown in the startup window if using that. > *Debian 12* required a single change to bld_prepare.sh to remove python2 > requirement. In addition, debian-testing and ubuntu-testing have now been > switched to the default of debian and ubuntu with their older operating > systems now being named as debian-older and ubuntu-older. > *Modifications* in the thirdparty Makefile and fileexr, filepng, filetga, > filetiff to ensure that builds continue to work in various distros, like > Arch and Slackware. > *Patches *to accommodate ffmpeg 6.0 and 4.4 for certain distros. > \o/ off into another month. MatN reported freeze on Deb11 32 bit but for him even older (mar 2022) version was doing the same, so ... stay tuned! I'll try to make Rosa 2016 x64 RPM and see how it goes there... -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] OT: comments from youtube can be saved, too
I wanted to add another paragraph to the Manual, explaining that the wording is not perfect and there may be unintentional descriptive errors anywhere. But then I read in the Introduction the already existing "Disclaimer" paragraph and thought that errors are already covered so am not going to worry about it. Below is the Disclaimer (which I am fairly certain mimics a standard disclaimer form from other manuals!) *Disclaimer* In this capacity, the author of this manual is not responsible for the function or errors of the software described in this manual. Great care has been taken in the creation of texts and illustrations. Nevertheless, errors cannot be completely excluded. However, the author cannot assume any legal responsibility or liability for incorrect information and its consequences. The author is grateful for suggestions for improvement and information on errors. On Mon, Aug 28, 2023 at 7:20 AM Andrea paz via Cin < cin@lists.cinelerra-gg.org> wrote: > @Phyllis > I edited the manual again so do not consider the previous attachment > valid, only this second one. > @All > In addition to eliminating my error (canvas = timeline) I made some > other small additions based on Igor Vladimirskji's articles (he gave > me permission). Can you check if they seem useful or are they to be > corrected? > > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] Monthly AppImage updates
Despite the potential for problems, late checkin of changes, and not too much testing, a new set of AppImages is now available for download. As always, if problems, simply revert to the previous AppImage. Changes includedare listed below. ** *Mirror* is a new user contributed new video plugin and has been documented in the Manual. *Gain *audio plugin has been improved to include the text box for precise designation of the gain and the clear/reset button to revert to the default. This was a user contribution. *Andrew contributions include:* The *About* in the Settings→Preferences now shows the Copyright to include the Cinelerra-GG team, the previous Cinelerra-CV team, as well as the libav version. This is also shown in the startup window if using that. *Debian 12* required a single change to bld_prepare.sh to remove python2 requirement. In addition, debian-testing and ubuntu-testing have now been switched to the default of debian and ubuntu with their older operating systems now being named as debian-older and ubuntu-older. *Modifications* in the thirdparty Makefile and fileexr, filepng, filetga, filetiff to ensure that builds continue to work in various distros, like Arch and Slackware. *Patches *to accommodate ffmpeg 6.0 and 4.4 for certain distros. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
чт, 31 авг. 2023 г., 16:16 Andrea paz : > I did some more testing for BR. > I noticed that to change the image type you just remove the "toggle" > and then from "Preferences" change format and give "Apply" (sometimes > you need "OK"). Almost always it works that way; at the limit you have > to diasbilitate BG, give "apply" then reactivate BG and give "apply." > At this point on the timeline you reapply the "Toggle" and get the > rendering in the new format. > I tried applying various filters and changing formats with those > filters. I tried playback and reverse playback. I never had any > crashes. > good then, thanks! > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
I did some more testing for BR. I noticed that to change the image type you just remove the "toggle" and then from "Preferences" change format and give "Apply" (sometimes you need "OK"). Almost always it works that way; at the limit you have to diasbilitate BG, give "apply" then reactivate BG and give "apply." At this point on the timeline you reapply the "Toggle" and get the rendering in the new format. I tried applying various filters and changing formats with those filters. I tried playback and reverse playback. I never had any crashes. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] CinGG 20230830 git code failure
чт, 31 авг. 2023 г., 14:39 Mat via Cin : > Hi, > > Pulled down git updates about 09 UTC today. > Built from scratch on Debian 11, 32 bit, Mint21.2 64 bit, and Fedora 38 > 64 bit, all on real hardware (not in VM). > Same hw or different in each case? > - Debian builds fine, CinGG itself, manual, appimagetool, and the > appimage itself. But any mesage box (e.g. starting .bcast dir > removed) freezes CinGG, you have to kill it from the terminal. The > error looks like > dbg_add, dup 11BC_Repeater 12BC_Clipboard > If I avoid a message box, simply load a video as project, sound doesn't > work, > neither with PulseAudio (mmap error) or Alsa (protocol error) as > device. Other applications work with Pulseaudio or Alsa (e.g. Audacity > uses Alsa). The video doesn´t play at all. > ow! yesterday I've build Deb11 64 bit VM, there was error in qemu 8.1 with default cpu, I added "-cpu host" and then it was fine ( on AMD FX 4300 cpu). I also build cingg in NetBSD 9.2 ( i think) i386 qemu vm, not really updated packages but just same os as I installed ~year ago. > - Mint 21.2 Apart from the python problem builds and works fine for > simple load-and-play HD video, did not try other actions. > Have not tried building AppImage tool yet. > well.. one good news! > - Fedora 38, builds CinGG proper fine, simple test is OK, although > there is a load ffmpeg error saying the there is no hardware > acceleration (vainfo and clinfo both show there is). Well, this is concerning! Can you show mediainfo and vainfo? Do other players work? Manual builds > fine too. But the AppImage tool doesn't build, error about too many > parameters somewhere. > > I try to see what's wrong with the AppImage tool on Fedora, time > permitting. > Welcome back to the party! So far I have only built regular single-user builds but can kick Slackware package creation or Rosa 2016 RPM action (this one after official source tarball appears in usual place) > MatN > -- > Cin mailing list > Cin@lists.cinelerra-gg.org > https://lists.cinelerra-gg.org/mailman/listinfo/cin > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
[Cin] CinGG 20230830 git code failure
Hi, Pulled down git updates about 09 UTC today. Built from scratch on Debian 11, 32 bit, Mint21.2 64 bit, and Fedora 38 64 bit, all on real hardware (not in VM). - Debian builds fine, CinGG itself, manual, appimagetool, and the appimage itself. But any mesage box (e.g. starting .bcast dir removed) freezes CinGG, you have to kill it from the terminal. The error looks like dbg_add, dup 11BC_Repeater 12BC_Clipboard If I avoid a message box, simply load a video as project, sound doesn't work, neither with PulseAudio (mmap error) or Alsa (protocol error) as device. Other applications work with Pulseaudio or Alsa (e.g. Audacity uses Alsa). The video doesn´t play at all. - Mint 21.2 Apart from the python problem builds and works fine for simple load-and-play HD video, did not try other actions. Have not tried building AppImage tool yet. - Fedora 38, builds CinGG proper fine, simple test is OK, although there is a load ffmpeg error saying the there is no hardware acceleration (vainfo and clinfo both show there is). Manual builds fine too. But the AppImage tool doesn't build, error about too many parameters somewhere. I try to see what's wrong with the AppImage tool on Fedora, time permitting. MatN -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
чт, 31 авг. 2023 г., 10:50 Andrea paz : > I tried leaving the BR on and also turning it off between trials (from > "Preferences" not "toggle"). I have tried disabling the BR and then > deleting the sequence manually. In this case, when I try a new > sequence in a different format I get a series of errors that it does > not find the previous jpg images and does not do the BR. Only by > restarting CinGG does the BR with new file types work again. > I will try more tests later trying to cause a crash. Question: is it > important to use "try ffpeg last/first"? Should I try both or should I > just use "last"? > For this specific test as far as can understand (from program behavior) cinelerra always use her native image file readers. So "ffmpeg first/last" shouldn't matter. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
I tried leaving the BR on and also turning it off between trials (from "Preferences" not "toggle"). I have tried disabling the BR and then deleting the sequence manually. In this case, when I try a new sequence in a different format I get a series of errors that it does not find the previous jpg images and does not do the BR. Only by restarting CinGG does the BR with new file types work again. I will try more tests later trying to cause a crash. Question: is it important to use "try ffpeg last/first"? Should I try both or should I just use "last"? -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
чт, 31 авг. 2023 г., 10:31 Andrea paz : > > Thanks! Did you try yesterday's scenario with bg render set to jpeg, > enabled, then set to any other compression / filetype, and re-enabled via > menu so you have red bar at top of topmost video track but at this point it > made from wrong image type so prev. version of file reading routines were > crashing? if you position playhead there? > > I don't quite understand the problem. > 1- No crash, but I don't know if I've done the steps you described > correctly. > 2- Creating a BRender in jpg, yes then disabling the BG. leave it on all the time? Going into > Preference and changing the BR from jpg sequence to EXR (and PNG) > sequence, creating a new BRender, I still have the jpeg sequence > active and no sequences were created with the other formats. > yes, I think? In previous version navigating this timeline will nearly instantly lead to crash due to libpng/libtiff/openexr being feed with wrong image. in new version you just get some chatter in terminal and black compositor window, so you stop bg render, start it anew, play with fader on video track a bit, park playhead at beginning and then re-creating of brender files actually starts, but with long enough timeline you still can outrace this process by mousing playback cursor around fast enough. Anyway, try wild things! earlier we get crash info - the better (even if not for tomorrow build due to time constrains) 3- Closed and restarted CinGG; created new BRender in tga: all OK. > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
> Thanks! Did you try yesterday's scenario with bg render set to jpeg, enabled, > then set to any other compression / filetype, and re-enabled via menu so you > have red bar at top of topmost video track but at this point it made from > wrong image type so prev. version of file reading routines were crashing? if > you position playhead there? I don't quite understand the problem. 1- No crash, but I don't know if I've done the steps you described correctly. 2- Creating a BRender in jpg, then disabling the BG. Going into Preference and changing the BR from jpg sequence to EXR (and PNG) sequence, creating a new BRender, I still have the jpeg sequence active and no sequences were created with the other formats. 3- Closed and restarted CinGG; created new BRender in tga: all OK. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
Re: [Cin] fileexr reading error handling
чт, 31 авг. 2023 г., 10:01 Andrea paz : > Compiling from last git: > > Compiling: OK (no crash; no errors) > > > Test with "Try ffmpeg last": > > Render EXR sequence: OK (43 fps) > > Load EXR sequence: OK > > Playback and effects on EXR sequence: OK > > > Other image sequences: OK > > EXR: 43 fps > PNG: 45 fps > TGA: 148 fps > TIFF: 149 fps > JPG: 166 fps > > Everything is OK, for me. Thanks. > I append cin5.log > Thanks! Did you try yesterday's scenario with bg render set to jpeg, enabled, then set to any other compression / filetype, and re-enabled via menu so you have red bar at top of topmost video track but at this point it made from wrong image type so prev. version of file reading routines were crashing? if you position playhead there? > -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin
