 |
New AppImages contain fix 20210228. |
|
|
Fixed in the AppImages of 20210228. |
|
|
@Andrew-R Your patch "fix_brender_direct_x11_jpeg.diff" did solve the problem but I was concerned that changing the colormodel would affect the results. So after 5 days of "programming by mutation" I discovered that the line in filelist.h: "int can_scale_input() { return 1; }" if changed to 0 instead, fixed the problem. BUT I do not know for sure if that will undo the "Resize bug for Filelist type assets, such as png, has been fixed." I tried to create the resize bug but did not know how to do that (tried proxy and resize track). I based my guess on what was done in filebase.h as in the last line of the following code: // Return either the argument or another colormodel which read_frame should // use. virtual int colormodel_supported(int colormodel) { return BC_RGB888; } // This file can copy compressed frames directly from the asset virtual int can_copy_from(Asset *asset, int64_t position) { return 0; } virtual int can_scale_input() { return 0; } Your discovery and possible fix for this bug has finally led to a solution that "I think" is correct. X11 direct was a valuable feature provided by the original programmer to speed up certain stuff. I will mark this resolved in a couple of days. There is a new AppImage for newer distros on the website with this patch in (as well as the Autosave backps). |
 |
from description, it sounds like single-frame PNG's (or other image?)' were not resizing properly? Not sure where you should set this resize . In asset window, may be? |
|
|
@Andrew-R The crash seems to happen when the modifications for filelist.h and filelist.C from 10/27/2020 were added. Reference is: "Resize bug for Filelist type assets, such as png, has been fixed." When I back out this mod, it no longer crashes but I can not remember where this bug came from and who reported it. And I do not know how to fix it !! |
|
|
Been working on this again today. With cincity's xml example file from the forum, I was able to reproduce the crash. I have narrowed it down to: Not Broken: commit a718f58e6d8061f83bd0c0b10848ac415cd21fcd Date: Sat Oct 24 16:21:55 2020 -0600 -- rework proxy for 1:1 and new layout, fix proxy for resized assets, change track gang_master patchbay flag use to allow disabled slaves Broken: commit c4c898707e3fdbf2979b7bc43ac0e1b0fa779663 Date: Tue Oct 27 16:37:06 2020 -0600 -- manual goto rework, resize asset/track tweaks and fixes, filelist resize fix, allow at least 1 vicon frame for target/src draw, update es.po Must be somewhere in the above. |
|
|
is there some possibility non-english locale interferes somehow? Also, does my patch ("fix_brender_direct_x11_jpeg.diff") helps? :} I noticed from dump txt crashing machine also has older AMD processor - probably related? ( AMD Phenom(tm) II X4 955 Processor) does change video output method helps? |
|
|
@Andrew-R Someone else is having a similar problem and I have not had a chance to reproduce the error I also had in Note 4550. Maybe there is more information that will help in the following forum entry on this: https://www.cinelerra-gg.org/forum/help-video/crash-on-background-rendering/#post-1594 |
|
|
some commands I used for "64-bit slackware installed in qemu as 64-bit chroot" (in russian but commands are all english :P) For 32-bit thing just install/unpack 32-bit distro in some folder .... https://www.linux.org.ru/forum/desktop/14777444 |
|
|
@Andrea_Paz yeah, apparently this page was deleted/archived from ArchWiki https://www.linuxsecrets.com/archlinux-wiki/wiki.archlinux.org/index.php/Install_bundled_32-bit_system_in_64-bit_system.html "Gnome-colors-add-files-to-archive.pngThis article is being considered for archiving.Gnome-colors-add-files-to-archive.png Reason: https://www.archlinux.org/news/phasing-out-i686-support/" But again, you can run any distro in chroot ... may even install on qemu/vbox and then copy content of their virtual disk to some directory and chroot in it Old-fashioned way, I know .... https://wiki.archlinux.org/index.php/Chroot - has some info But if you run x86_64 kernel (like I do) you *can* have main 32-bit system and 64-bit chroot, or main 64-bit system and 32-bit chroot. (I run multilib chroot of Rosa Linux this way) On 32-bit kernel you can't run 64-bit userspace (at least not without things like qemu, it will be SLOW) |
 |
Sorry, but from the guides I've found (nothing for Arch Linux) I can't figure out how to do 32-bit chroot. |
|
|
@Andrew-R I am not sure that this is only a local problem because it crashed for me also BUT I think the steps I used included some step that I can not remember. I downloaded your file and tested that too without a crash. Will test some more when I get time to see if I can get it to crash again and this time I will try to be more vigilant in the steps I use. |
|
|
@Andrea_Paz , so most likely this is my local problem. If you have 32-bit chroot around - can you test there, too ? |
|
|
I've done some tests and everything works normally. Sometimes I have problems with the set range, which is not respected and starts from the insertion point to the end of the timeline. But no crashes. Here is an example of terminal output: " BRenderThread::start 1 map=562 equivalent=31 brender_start=31 result=31 end=211 RenderFarmClient::main_loop: Session started from /tmp/cinelerra.e01ce6ba-e919-4a06-b266-63e2cc1ecb53 RenderFarmClientThread::run: Session finished. " |
|
|
@PhyllisSmith, I'm sorry for adding more load on you ...... Strangely enough it works if I load jpeg file(s) directly into timeline - only background render result in this crash for me ... Moment, I'll upload specific sample .... Try this file: https://cloud.mail.ru/public/KKY8/o86j62p2z Load it, select region, turn bg render ON, hit 'space' (play) .....For me it crashed reliably :/ May be you use X11 non-direct, or other mode? I only was able to crash it in X11-direct, but this is apparently new install default setting :/ |
|
|
Hmmmm.... I got it to crash once on a different jpg file but then could not reproduce so there must be a definitive step required that I did not do the second time. Still testing. |
|
|
@Andrew-R About: "I wonder if anyone ELSE getting this crash, and if so - can my hack be accepted in absence of real solution ....." It did not crash for me on my first attempt. But I will try a different jpg file. |
|
|
So, for now I hacked filejpeg.C for returning different corlormodel. I wonder if anyone ELSE getting this crash, and if so - can my hack be accepted in absence of real solution .....
fix_brender_direct_x11_jpeg.diff (579 bytes) |
|
|
so, I uncommented few lines in filejpeg.C: diff --git a/cinelerra-5.1/cinelerra/filejpeg.C b/cinelerra-5.1/cinelerra/filejpeg.C index 42dd2189..104a2ed5 100644 --- a/cinelerra-5.1/cinelerra/filejpeg.C +++ b/cinelerra-5.1/cinelerra/filejpeg.C @@ -101,12 +101,16 @@ int FileJPEG::can_copy_from(Asset *asset, int64_t position) int FileJPEG::colormodel_supported(int colormodel) { + printf("colormodel in filejpeg: %i \n ", colormodel); return colormodel; } int FileJPEG::get_best_colormodel(Asset *asset, int driver) { + + printf("Driver in filejpeg: %i \n ", driver); + switch(driver) { case PLAYBACK_X11: @@ -286,14 +290,14 @@ int FileJPEG::read_frame(VFrame *output, VFrame *input) if( !decompressor ) decompressor = mjpeg_new(asset->width, asset->height, 1); -// printf("FileJPEG::read_frame %d %p %d %d %d %p %p %p %p %d\n", __LINE__, -// input->get_data(), input->get_compressed_size(), output->get_w(), output->get_h(), -// output->get_rows(), output->get_y(), output->get_u(), output->get_v(), -// output->get_color_model()); + printf("FileJPEG::read_frame %d %p %d %d %d %p %p %p %p %d\n", __LINE__, + input->get_data(), input->get_compressed_size(), output->get_w(), output->get_h(), + output->get_rows(), output->get_y(), output->get_u(), output->get_v(), + output->get_color_model()); mjpeg_decompress((mjpeg_t*)decompressor, input->get_data(), input->get_compressed_size(), 0, output->get_rows(), output->get_y(), output->get_u(), output->get_v(), output->get_color_model(), 1); -//printf("FileJPEG::read_frame %d\n", __LINE__); +printf("FileJPEG::read_frame %d\n", __LINE__); // return 0; } ==== and this gives me ..... colormodel in filejpeg: 6 colormodel in filejpeg: 6 FileJPEG::read_frame 293 0xf56b8000 11844 684 388 0xd035a470 (nil) (nil) (nil) 6 ** segv at 0x8864d05 in pid 16424, tid 16544 signal_entry_recoverable: got SIGPIPE my pid=16526 signal_entry_recoverable: got SIGPIPE my pid=16526 Ошибка сегментирования so, apparently output->get_y , output->get_u and output->get_v are nil ?!!! |
|
|
valgrind log Still points at BC_Xfer::xfer_yuv420p_to_bgr8888 I tried to figure out what was wrong with this autogenerated function (by python script.....) function but not successed ... :/ Function lives after compilation in root@slax:/dev/shm/tmp/cinelerra-goodguy-20210112/cinelerra-5.1/cinelerra# grep xfer_yuv420p_to_bgr8888 ../guicast/xfer/*.C ../guicast/xfer/xfer.C: &BC_Xfer::xfer_yuv420p_to_bgr8888, &BC_Xfer::xfer_yuv420p_to_yuv420p, ../guicast/xfer/xfer_bc_yuv420p.C:void BC_Xfer::xfer_yuv420p_to_bgr8888 (unsigned y0, unsigned y1) { I thought it was missing a in bgr8888 format, but apparently not ..... Both C files as generated here attached ...... valgrind.log (12,869 bytes) xfer.C (65,897 bytes) xfer_bc_yuv420p.C (10,631 bytes) |
|
|
dump (from user) cinelerra_30567.dmp (149,670 bytes) |
- Anonymous
