fileexr reading error handling
Using https://openexr.com/en/latest/HelloWorld.html as example so for now I have base commit d51dc1ff2dbd920c6488af4380b8064c9b6a7b4c (origin/master, origin/HEAD) Author: Good Guy <[email protected]> Date: Tue Aug 29 20:20:10 2023 -0600 Credit Andrew - rest of fix for Arch (and termux) which includes thirdparty/Makefile plus commit afa6a601fd3228be18aef413061b3d0165344d7c (HEAD -> master) Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 07:27:57 2023 +0300 Fileext reading error handling for bg render commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 05:27:10 2023 +0300 Add libjpeg dep to.libtiff in thirdparty/Makefile commit 8297b38e49da0ce73e119138c158e806eb1fb45d Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 02:48:47 2023 +0300 Possible fix for ffmpeg 4.4 in pluginfclient.C ==== so, ffmpeg 5.1 based cin seems to work on Slackware 15.0 i586 (with some self-build packages). Tested adding ffmpeg video filter to video track, and of course background render with on-the-fly compressor switch. aggrh, in commit message fileert instead of fileexr. I hope this is not a big problem will try my virtual machines next
Andrew, I do not think that the c++ code "try" is going to work -- it is never used anywhere else and probably for a good reason. Is there an alternative? Fileext reading error handling for bg render
commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 05:27:10 2023 +0300
ср, 30 авг. 2023 г., 18:25 Phyllis Smith <[email protected]>:
Andrew, I do not think that the c++ code "try" is going to work -- it is never used anywhere else and probably for a good reason. Is there an alternative?
well, this is official way openexr does error handling ... it also fixes my error (try to switch from brender/jpeg to brender /exr without removing those brender files - without patch we crash as soon as openexr meet wrong input ....) and print error message in this case. so it obviously work at least on c++11 compilers (enforced by openexr itself)
Fileext reading error handling for bg render
commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 05:27:10 2023 +0300
Builds and at least renders png, tga, tiff, and exr sequences with the following additional patches: 0001-Possible-fix-for-ffmpeg-4.4-in-pluginfclient.C.patch 0001-Add-libjpeg-dep-to.libtiff-in-thirdparty-Makefile.patch 0001-Fileext-reading-error-handling-for-bg-render.patch 0001-More-error-handling-in-filepng-sorry.patch Off the computer now for several hours. On Tue, Aug 29, 2023 at 10:46 PM Andrew Randrianasulu < [email protected]> wrote:
Using https://openexr.com/en/latest/HelloWorld.html as example
so for now I have base
commit d51dc1ff2dbd920c6488af4380b8064c9b6a7b4c (origin/master, origin/HEAD) Author: Good Guy <[email protected]> Date: Tue Aug 29 20:20:10 2023 -0600
Credit Andrew - rest of fix for Arch (and termux) which includes thirdparty/Makefile
plus
commit afa6a601fd3228be18aef413061b3d0165344d7c (HEAD -> master) Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 07:27:57 2023 +0300
Fileext reading error handling for bg render
commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 05:27:10 2023 +0300
Add libjpeg dep to.libtiff in thirdparty/Makefile
commit 8297b38e49da0ce73e119138c158e806eb1fb45d Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 02:48:47 2023 +0300
Possible fix for ffmpeg 4.4 in pluginfclient.C
====
so, ffmpeg 5.1 based cin seems to work on Slackware 15.0 i586 (with some self-build packages).
Tested adding ffmpeg video filter to video track, and of course background render with on-the-fly compressor switch.
aggrh, in commit message fileert instead of fileexr. I hope this is not a big problem
will try my virtual machines next
Andrew, could you check the final GIT checkin to make sure I got it right? I found no problems but only minimal testing. Andrea, if you have a chance to build from the latest GIT and send me email before I start AppImage builds on the 31st that all seems probably OK, that would be appreciated. As described below, all should be included plus the libpng "0001-More-error-handling-in-filepng-sorry.patch" in the final GIT checkin. At least, I think I got it right! Thanks, Andrew On Tue, Aug 29, 2023 at 10:46 PM Andrew Randrianasulu < [email protected]> wrote:
Using https://openexr.com/en/latest/HelloWorld.html as example
so for now I have base
commit d51dc1ff2dbd920c6488af4380b8064c9b6a7b4c (origin/master, origin/HEAD) Author: Good Guy <[email protected]> Date: Tue Aug 29 20:20:10 2023 -0600
Credit Andrew - rest of fix for Arch (and termux) which includes thirdparty/Makefile
plus
commit afa6a601fd3228be18aef413061b3d0165344d7c (HEAD -> master) Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 07:27:57 2023 +0300
Fileext reading error handling for bg render
commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 05:27:10 2023 +0300
Add libjpeg dep to.libtiff in thirdparty/Makefile
commit 8297b38e49da0ce73e119138c158e806eb1fb45d Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 02:48:47 2023 +0300
Possible fix for ffmpeg 4.4 in pluginfclient.C
====
so, ffmpeg 5.1 based cin seems to work on Slackware 15.0 i586 (with some self-build packages).
Tested adding ffmpeg video filter to video track, and of course background render with on-the-fly compressor switch.
aggrh, in commit message fileert instead of fileexr. I hope this is not a big problem
will try my virtual machines next
On Thu, Aug 31, 2023 at 12:59 AM Phyllis Smith <[email protected]> wrote:
Andrew, could you check the final GIT checkin to make sure I got it right? I found no problems but only minimal testing. Andrea, if you have a chance to build from the latest GIT and send me email before I start AppImage builds on the 31st that all seems probably OK, that would be appreciated.
As described below, all should be included plus the libpng "0001-More-error-handling-in-filepng-sorry.patch" in the final GIT checkin. At least, I think I got it right! Thanks, Andrew
Thank YOU for working all the time (overtime) on my goofs! I think it worked ok with std. ffmpeg 5.1 build 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 bash-5.1$ bin/cin Cinelerra Infinity - built: Aug 31 2023 01:21:43 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy 2003-2017 mods for Cinelerra-CV by CinelerraCV team 2015-2023 mods for Cinelerra-GG by Cinelerra-GG team Libav version: Lavc58.134.100 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. build plugin index for: /dev/shm/cinelerra/cinelerra-5.1/bin/plugins [azmq_108 @ 0x9e9bdc0] Could not bind ZMQ socket to address 'tcp://*:5555': Address already in use PluginFFilter::new_ffilter(azmq) err: Generic error in an external library ** segv at 0x8539cc4 in pid 18493, tid 18493 writing debug data to /tmp/cinelerra_18493.dmp lock_items: 0 lock_frees: 4 Ошибка сегментирования bash-5.1$ bin/cin Cinelerra Infinity - built: Aug 31 2023 01:21:43 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy 2003-2017 mods for Cinelerra-CV by CinelerraCV team 2015-2023 mods for Cinelerra-GG by Cinelerra-GG team Libav version: Lavc58.134.100 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. build plugin index for: /dev/shm/cinelerra/cinelerra-5.1/bin/plugins [azmq_132 @ 0xaaa5080] Could not bind ZMQ socket to address 'tcp://*:5555': Address already in use PluginFFilter::new_ffilter(azmq) err: Generic error in an external library ** segv at 0x8539cc4 in pid 18508, tid 18508 writing debug data to /tmp/cinelerra_18508.dmp lock_items: 0 lock_frees: 4 Ошибка сегментирования bash-5.1$ mcedit bin/plugins/ audio/ posterize.plugin themes/ fonts/ scopes/ timelapsehelper.plugin picon/ shapes/ video/ bash-5.1$ mcedit bin/ffmpeg/ audio/ encode.opts flv.dfl plugin.opts decode.opts ffmpeg.opts format/ video/ bash-5.1$ mcedit bin/ffmpeg/ plugin.opts bash-5.1$ mcedit bin/ffmpeg/plugin.opts bash-5.1$ bin/cin Cinelerra Infinity - built: Aug 31 2023 01:21:43 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy 2003-2017 mods for Cinelerra-CV by CinelerraCV team 2015-2023 mods for Cinelerra-GG by Cinelerra-GG team Libav version: Lavc58.134.100 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. build plugin index for: /dev/shm/cinelerra/cinelerra-5.1/bin/plugins [azmq_132 @ 0xa60e400] Could not bind ZMQ socket to address 'tcp://*:5555': Address already in use PluginFFilter::new_ffilter(azmq) err: Generic error in an external library ** segv at 0x8539cc4 in pid 18602, tid 18602 writing debug data to /tmp/cinelerra_18602.dmp lock_items: 0 lock_frees: 4 Ошибка сегментирования bash-5.1$ mcedit bin/ffmpeg/plugin.opts bash-5.1$ bin/cin Cinelerra Infinity - built: Aug 31 2023 01:21:43 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy 2003-2017 mods for Cinelerra-CV by CinelerraCV team 2015-2023 mods for Cinelerra-GG by Cinelerra-GG team Libav version: Lavc58.134.100 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. build plugin index for: /dev/shm/cinelerra/cinelerra-5.1/bin/plugins [zmq_807 @ 0xa3ed8c0] Could not bind ZMQ socket to address 'tcp://*:5555': Address already in use PluginFFilter::new_ffilter(zmq) err: Generic error in an external library ** segv at 0x8539cc4 in pid 18652, tid 18652 writing debug data to /tmp/cinelerra_18652.dmp lock_items: 0 lock_frees: 4 Ошибка сегментирования bash-5.1$ mcedit bin/ffmpeg/plugin.opts bash-5.1$ bin/cin Cinelerra Infinity - built: Aug 31 2023 01:21:43 git://git.cinelerra-gg.org/goodguy/cinelerra.git (c) 2006-2019 Heroine Virtual Ltd. by Adam Williams 2007-2020 mods for Cinelerra-GG by W.P.Morrow aka goodguy 2003-2017 mods for Cinelerra-CV by CinelerraCV team 2015-2023 mods for Cinelerra-GG by Cinelerra-GG team Libav version: Lavc58.134.100 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. build plugin index for: /dev/shm/cinelerra/cinelerra-5.1/bin/plugins RenderFarmClient::main_loop: client started BRenderThread::start 1 map=0 equivalent=0 brender_start=67 result=67 end=654 RenderFarmClient::main_loop: Session started from /tmp/cinelerra.b7500279-f3bf-41f4-883c-8a4e0ee53cc4 RenderFarmClientThread::run: Session finished. BRenderThread::start 1 map=654 equivalent=0 brender_start=0 result=0 end=654 RenderFarmClient::main_loop: Session started from /tmp/cinelerra.b7500279-f3bf-41f4-883c-8a4e0ee53cc4 RenderFarmClientThread::run: Session finished. BRenderThread::start 1 map=654 equivalent=654 brender_start=0 result=654 end=654 RenderFarmClient::main_loop: Session started from /tmp/cinelerra.b7500279-f3bf-41f4-883c-8a4e0ee53cc4 RenderFarmClientThread::run: Session finished. [skip] full file attached.
On Tue, Aug 29, 2023 at 10:46 PM Andrew Randrianasulu <[email protected]> wrote:
Using https://openexr.com/en/latest/HelloWorld.html as example
so for now I have base
commit d51dc1ff2dbd920c6488af4380b8064c9b6a7b4c (origin/master, origin/HEAD) Author: Good Guy <[email protected]> Date: Tue Aug 29 20:20:10 2023 -0600
Credit Andrew - rest of fix for Arch (and termux) which includes thirdparty/Makefile
plus
commit afa6a601fd3228be18aef413061b3d0165344d7c (HEAD -> master) Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 07:27:57 2023 +0300
Fileext reading error handling for bg render
commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 05:27:10 2023 +0300
Add libjpeg dep to.libtiff in thirdparty/Makefile
commit 8297b38e49da0ce73e119138c158e806eb1fb45d Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 02:48:47 2023 +0300
Possible fix for ffmpeg 4.4 in pluginfclient.C
====
so, ffmpeg 5.1 based cin seems to work on Slackware 15.0 i586 (with some self-build packages).
Tested adding ffmpeg video filter to video track, and of course background render with on-the-fly compressor switch.
aggrh, in commit message fileert instead of fileexr. I hope this is not a big problem
will try my virtual machines next
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.
пт, 1 сент. 2023 г., 00:23 Phyllis Smith <[email protected]>:
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.
чт, 31 авг. 2023 г., 00:59 Phyllis Smith <[email protected]>:
Andrew, could you check the final GIT checkin to make sure I got it right? I found no problems but only minimal testing.
I also build (and playback-tested) current git + ffmpeg 6.0 on termux/aarch64 (ok) and FreeBSD 13.0 amd64 (also ok). so, hopefully good to go. Andrea, if you have a chance to build from the latest GIT and send me email
before I start AppImage builds on the 31st that all seems probably OK, that would be appreciated.
As described below, all should be included plus the libpng "0001-More-error-handling-in-filepng-sorry.patch" in the final GIT checkin. At least, I think I got it right! Thanks, Andrew
On Tue, Aug 29, 2023 at 10:46 PM Andrew Randrianasulu < [email protected]> wrote:
Using https://openexr.com/en/latest/HelloWorld.html as example
so for now I have base
commit d51dc1ff2dbd920c6488af4380b8064c9b6a7b4c (origin/master, origin/HEAD) Author: Good Guy <[email protected]> Date: Tue Aug 29 20:20:10 2023 -0600
Credit Andrew - rest of fix for Arch (and termux) which includes thirdparty/Makefile
plus
commit afa6a601fd3228be18aef413061b3d0165344d7c (HEAD -> master) Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 07:27:57 2023 +0300
Fileext reading error handling for bg render
commit cac447973db936f7d5594c83521c34f3e5a9c187 Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 05:27:10 2023 +0300
Add libjpeg dep to.libtiff in thirdparty/Makefile
commit 8297b38e49da0ce73e119138c158e806eb1fb45d Author: Andrew Randrianasulu <[email protected]> Date: Wed Aug 30 02:48:47 2023 +0300
Possible fix for ffmpeg 4.4 in pluginfclient.C
====
so, ffmpeg 5.1 based cin seems to work on Slackware 15.0 i586 (with some self-build packages).
Tested adding ffmpeg video filter to video track, and of course background render with on-the-fly compressor switch.
aggrh, in commit message fileert instead of fileexr. I hope this is not a big problem
will try my virtual machines next
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
чт, 31 авг. 2023 г., 10:01 Andrea paz <[email protected]>:
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?
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.
чт, 31 авг. 2023 г., 10:31 Andrea paz <[email protected]>:
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.
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"?
чт, 31 авг. 2023 г., 10:50 Andrea paz <[email protected]>:
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.
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.
чт, 31 авг. 2023 г., 16:16 Andrea paz <[email protected]>:
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!
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 <[email protected]> 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.
пт, 1 сент. 2023 г., 01:27 Phyllis Smith <[email protected]>:
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 <[email protected]> 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.
On Fri, Sep 1, 2023 at 1:59 AM Andrew Randrianasulu <[email protected]> wrote:
пт, 1 сент. 2023 г., 01:27 Phyllis Smith <[email protected]>:
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 <[email protected]> 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.
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Phyllis Smith