В сообщении от Saturday 21 March 2020 03:39:18 Phyllis Smith написал(а):
Andrew, the latest GIT checkin fixes the crash and provides a warning as you suggested. It works on the latest 2.4.1 version as there were some code improvements over the 2.2.1. Try it now.
Seems to work (tried to launch just-compiled Cin without waiting for opencv build to finish ...) Still, at 5am I have this brilliant idea about adding nasm to thirdparty/ directory :} of course, real fun will be convincing both x264/x265 and libdav1d (and may be even ffmpeg?) to use it. I'm not sure if just altering PATH will be enough. At least x264 seems to look for $AS, so it not hardcoded there? AS="${AS-nasm}" ffmpeg have this config option: --x86asmexe=EXE use nasm-compatible assembler EXE [$x86asmexe_default] and x265 uses something from Cmake. Still, considering list of distros having nasm 2.10 (!) ..... may be it really worth trying (from NASM_levels.txt attached to BT390)
Also, minor bug:
If I render OpenEXR sequence, load it, play it, and then delete main image files but NOT index *.exrs - and try to load file from "recent files" sub-menu in main menu - Cin will terminate
Easily reproduced here. GG says OpenExr is doing a "throw" and Cinelerra normally does not "catch". This would be the very first "catch" in Cinelerra if it would be added and that is not the way gg wants to go unless we absolutely have to. This requires the error handling characteristics of the C++ runtime library. If you do that same thing with a TIFF sequence, it passes the error correctly back to Cinelerra to field instead of crash.
H, sorry for such suggestion without patch - but can't be OpenEXR sequence file validated before passing it into library?
Of course, on multiproces/user system user may delete files right after they passes test of existence ....
May be just document it? :}
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin