Patches again - filepng, opencv config
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature! I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it. It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits". By default Cin adds encoded results into resources and on new tracks - you clearly can see it will be black/broken. 8-bits PNGs are OK. Ubuntu image I used: http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/ xubuntu-18.04.4-desktop-amd64.iso - 1.4 Gb Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image: guest@slax:/dev/shm$ wget http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... --2020-03-25 13:55:42-- http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso» xubuntu-18.04.4-desktop-amd64.iso 100%[==============================================================================================================>] 1,43G 8,26MB/s за 6m 40s 2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904] guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu) Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0 this will create 1Gb sized compressed swap in ram I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb). NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there .... Still, this is something strange, I'll try to contact libpng author about this..... Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system. I still use opencv-20180401.tgz I also have two lame (mp3lame) patches, but will send them separately.
Andrew, We have not given up on this yet but really do not understand the png little endian issue. When gg looks through the png code it is very insistent that with the meaning of png being Portable *Network* Graphics. The emphasis on Network does not allow for little endian. ------------------------------ ./libpng.3:the Portable Network Graphics (PNG) format image files. It uses the ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng-manual.txt:PNG files store 16-bit pixels in network byte order (big-endian, ----------------------------- Sorry for our confusion; I hope we can get this figured out but all indications on our computers and in the code is only Big endian. On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new tracks - you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used: http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/ xubuntu-18.04.4-desktop-amd64.iso <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso> - 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... --2020-03-25 <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso--2020-03-25> 13:55:42-- http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso 100%[==============================================================================================================>] 1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Friday 27 March 2020 22:38:29 Phyllis Smith написал(а):
Andrew, We have not given up on this yet but really do not understand the png little endian issue. When gg looks through the png code it is very insistent that with the meaning of png being Portable *Network* Graphics. The emphasis on Network does not allow for little endian. ------------------------------ ./libpng.3:the Portable Network Graphics (PNG) format image files. It uses the ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng-manual.txt:PNG files store 16-bit pixels in network byte order (big-endian, ----------------------------- Sorry for our confusion; I hope we can get this figured out but all indications on our computers and in the code is only Big endian.
But my machine is LE! * And libPNG doesn't do this swap by default ONLY for those newly-introduced 16 bit per color channel format, at least in my tests! Did you tried to look at Cin PNG output in both cases? (8 bpc default, 16 - when you select it) *Actually, I wish to test on qemu-system-ppc, but this take a lot of time - because emulated Mac is only single-core ..... and full emulation easily can slow down your Instructions per second 10x down! So, it will be 4x slower by being single core, and 10x at least slower again due to system emulation (kvm can't help here).. so, 1 hour will become 40!
On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new tracks - you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used: http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/ xubuntu-18.04.4-desktop-amd64.iso <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso> - 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... --2020-03-25 <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso--2020-03-25> 13:55:42-- http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso 100%[==============================================================================================================>] 1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Well, gg looked every where he could think of to obviously include libpng and could find absolutely no place where the "endian"ness was stored. Still confused here. On Fri, Mar 27, 2020 at 2:24 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Friday 27 March 2020 22:38:29 Phyllis Smith написал(а):
Andrew, We have not given up on this yet but really do not understand the png little endian issue. When gg looks through the png code it is very insistent that with the meaning of png being Portable *Network* Graphics. The emphasis on Network does not allow for little endian. ------------------------------ ./libpng.3:the Portable Network Graphics (PNG) format image files. It uses the ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng-manual.txt:PNG files store 16-bit pixels in network byte order (big-endian, ----------------------------- Sorry for our confusion; I hope we can get this figured out but all indications on our computers and in the code is only Big endian.
But my machine is LE! * And libPNG doesn't do this swap by default ONLY for those newly-introduced 16 bit per color channel format, at least in my tests!
Did you tried to look at Cin PNG output in both cases? (8 bpc default, 16 - when you select it)
*Actually, I wish to test on qemu-system-ppc, but this take a lot of time - because emulated Mac is only single-core ..... and full emulation easily can slow down your Instructions per second 10x down!
So, it will be 4x slower by being single core, and 10x at least slower again due to system emulation (kvm can't help here).. so, 1 hour will become 40!
On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new tracks - you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used: http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/ xubuntu-18.04.4-desktop-amd64.iso <
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
- 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
--2020-03-25 < http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
13:55:42--
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso
100%[==============================================================================================================>]
1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Saturday 28 March 2020 00:11:13 Phyllis Smith написал(а):
Well, gg looked every where he could think of to obviously include libpng and could find absolutely no place where the "endian"ness was stored. Still confused here.
May be it really not stored, but ASSUMED?
On Fri, Mar 27, 2020 at 2:24 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Friday 27 March 2020 22:38:29 Phyllis Smith написал(а):
Andrew, We have not given up on this yet but really do not understand the png little endian issue. When gg looks through the png code it is very insistent that with the meaning of png being Portable *Network* Graphics. The emphasis on Network does not allow for little endian. ------------------------------ ./libpng.3:the Portable Network Graphics (PNG) format image files. It uses the ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng-manual.txt:PNG files store 16-bit pixels in network byte order (big-endian, ----------------------------- Sorry for our confusion; I hope we can get this figured out but all indications on our computers and in the code is only Big endian.
But my machine is LE! * And libPNG doesn't do this swap by default ONLY for those newly-introduced 16 bit per color channel format, at least in my tests!
Did you tried to look at Cin PNG output in both cases? (8 bpc default, 16 - when you select it)
*Actually, I wish to test on qemu-system-ppc, but this take a lot of time - because emulated Mac is only single-core ..... and full emulation easily can slow down your Instructions per second 10x down!
So, it will be 4x slower by being single core, and 10x at least slower again due to system emulation (kvm can't help here).. so, 1 hour will become 40!
On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new tracks - you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used: http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/ xubuntu-18.04.4-desktop-amd64.iso <
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
- 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
--2020-03-25 < http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
13:55:42--
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso
100%[==============================================================================================================>]
1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrew, We thought of another png experiment that we are going to try tomorrow. Both our laptop and desktop are AMD and thus are necessarily *little*- *endian*. On Fri, Mar 27, 2020 at 3:51 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Saturday 28 March 2020 00:11:13 Phyllis Smith написал(а):
Well, gg looked every where he could think of to obviously include libpng and could find absolutely no place where the "endian"ness was stored. Still confused here.
May be it really not stored, but ASSUMED?
On Fri, Mar 27, 2020 at 2:24 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Friday 27 March 2020 22:38:29 Phyllis Smith написал(а):
Andrew, We have not given up on this yet but really do not understand the png little endian issue. When gg looks through the png code it is very insistent that with the meaning of png being Portable *Network*
Graphics.
The emphasis on Network does not allow for little endian. ------------------------------ ./libpng.3:the Portable Network Graphics (PNG) format image files. It uses the ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng-manual.txt:PNG files store 16-bit pixels in network byte order (big-endian, ----------------------------- Sorry for our confusion; I hope we can get this figured out but all indications on our computers and in the code is only Big endian.
But my machine is LE! * And libPNG doesn't do this swap by default ONLY for those newly-introduced 16 bit per color channel format, at least in my tests!
Did you tried to look at Cin PNG output in both cases? (8 bpc default, 16 - when you select it)
*Actually, I wish to test on qemu-system-ppc, but this take a lot of time - because emulated Mac is only single-core ..... and full emulation easily can slow down your Instructions per second 10x down!
So, it will be 4x slower by being single core, and 10x at least slower again due to system emulation (kvm can't help here).. so, 1 hour will become 40!
On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new
tracks -
you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used:
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/
xubuntu-18.04.4-desktop-amd64.iso <
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
- 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
--2020-03-25 <
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
13:55:42--
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso
100%[==============================================================================================================>]
1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Saturday 28 March 2020 05:48:42 Phyllis Smith написал(а):
Andrew, We thought of another png experiment that we are going to try tomorrow. Both our laptop and desktop are AMD and thus are necessarily *little*- *endian*.
So, have good night ...and ..stay safe. (world news are a bit worrying). After all, this is voluntary work, if even google was about to skip/delay next broswer release - why can't we?
On Fri, Mar 27, 2020 at 3:51 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Saturday 28 March 2020 00:11:13 Phyllis Smith написал(а):
Well, gg looked every where he could think of to obviously include libpng and could find absolutely no place where the "endian"ness was stored. Still confused here.
May be it really not stored, but ASSUMED?
On Fri, Mar 27, 2020 at 2:24 PM Andrew Randrianasulu < [email protected]> wrote:
В сообщении от Friday 27 March 2020 22:38:29 Phyllis Smith написал(а):
Andrew, We have not given up on this yet but really do not understand the png little endian issue. When gg looks through the png code it is very insistent that with the meaning of png being Portable *Network*
Graphics.
The emphasis on Network does not allow for little endian. ------------------------------ ./libpng.3:the Portable Network Graphics (PNG) format image files. It uses the ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng.3:PNG files store 16-bit pixels in network byte order (big-endian, ./libpng-manual.txt:PNG files store 16-bit pixels in network byte order (big-endian, ----------------------------- Sorry for our confusion; I hope we can get this figured out but all indications on our computers and in the code is only Big endian.
But my machine is LE! * And libPNG doesn't do this swap by default ONLY for those newly-introduced 16 bit per color channel format, at least in my tests!
Did you tried to look at Cin PNG output in both cases? (8 bpc default, 16 - when you select it)
*Actually, I wish to test on qemu-system-ppc, but this take a lot of time - because emulated Mac is only single-core ..... and full emulation easily can slow down your Instructions per second 10x down!
So, it will be 4x slower by being single core, and 10x at least slower again due to system emulation (kvm can't help here).. so, 1 hour will become 40!
On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new
tracks -
you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used:
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/
xubuntu-18.04.4-desktop-amd64.iso <
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
- 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
--2020-03-25 <
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
13:55:42--
http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt...
Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso
100%[==============================================================================================================>]
1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Sorry, we figured out what happened. I was fooled by the filepng write_frame function. It uses a test to see if what it is writing can be a "direct_copy". So... whenever I added your patch to test it, and ran the png render, my test data was a png, and it always just copied it instead of testing your patch. I was tricked into believing your patch had no effect. That was incorrect, it is needed. Turns out the swap is to present the data in network order to the interface. My mistake... When I used a synthetic render (gradient only), the writer can't just copy it. It has to be compressed. The test indicates your mod is needed for sure. I added the change just as soon as I realized what had happened. Well, just goes to show that good testing is the road to hell. On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new tracks - you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used: http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/ xubuntu-18.04.4-desktop-amd64.iso <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso> - 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... --2020-03-25 <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso--2020-03-25> 13:55:42-- http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso 100%[==============================================================================================================>] 1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
В сообщении от Monday 30 March 2020 03:48:42 Good Guy написал(а):
Sorry, we figured out what happened. I was fooled by the filepng write_frame function. It uses a test to see if what it is writing can be a "direct_copy". So... whenever I added your patch to test it, and ran the png render, my test data was a png, and it always just copied it instead of testing your patch. I was tricked into believing your patch had no effect. That was incorrect, it is needed. Turns out the swap is to present the data in network order to the interface. My mistake...
When I used a synthetic render (gradient only), the writer can't just copy it. It has to be compressed. The test indicates your mod is needed for sure. I added the change just as soon as I realized what had happened.
Well, just goes to show that good testing is the road to hell.
Oh, thanks A LOT for this update, now I can leave my machine compiling, my dog sleeping, and do the same until he wake me up in the morning!
On Thu, Mar 26, 2020 at 8:46 PM Andrew Randrianasulu < [email protected]> wrote:
Sorry for insisting on this filepng part - but it was my work, and I dislike to ship broken feature!
I actually tested Cinelerra git on Ubuntu Live DVD, and _16 bit_ pngs were broken there without it.
It was as simple as 1) opening the video 2) setting project to rgba-float color format. 3) trying to save png (from non-black area of timeline) and set options to "with alpha, 16 bits".
By default Cin adds encoded results into resources and on new tracks - you clearly can see it will be black/broken. 8-bits PNGs are OK.
Ubuntu image I used: http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/ xubuntu-18.04.4-desktop-amd64.iso <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso> - 1.4 Gb
Then I created 4 Gb file in tmpfs, formatted it with btrfs with compression, and booted Live image:
guest@slax:/dev/shm$ wget http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... --2020-03-25 <http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubuntu-18.04.4-desktop-amd64.iso--2020-03-25> 13:55:42-- http://mirror.yandex.ru/ubuntu-cdimage/xubuntu/releases/18.04/release/xubunt... Распознаётся mirror.yandex.ru… 213.180.204.183, 2a02:6b8::183 Подключение к mirror.yandex.ru|213.180.204.183|:80... соединение установлено. HTTP-запрос отправлен. Ожидание ответа… 200 OK Длина: 1534459904 (1,4G) [application/octet-stream] Сохранение в: «xubuntu-18.04.4-desktop-amd64.iso»
xubuntu-18.04.4-desktop-amd64.iso 100%[==============================================================================================================>] 1,43G 8,26MB/s за 6m 40s
2020-03-25 14:02:28 (3,66 MB/s) - «xubuntu-18.04.4-desktop-amd64.iso» сохранён [1534459904/1534459904]
guest@slax:/dev/shm$ qemu-sy qemu-system-aarch64 qemu-system-i386 qemu-system-mips qemu-system-nios2 qemu-system-riscv64 qemu-system-sparc64 qemu-system-xtensaeb qemu-system-alpha qemu-system-lm32 qemu-system-mips64 qemu-system-or1k qemu-system-s390x qemu-system-tricore qemu-system-arm qemu-system-m68k qemu-system-mips64el qemu-system-ppc qemu-system-sh4 qemu-system-unicore32 qemu-system-cris qemu-system-microblaze qemu-system-mipsel qemu-system-ppc64 qemu-system-sh4eb qemu-system-x86_64 qemu-system-hppa qemu-system-microblazeel qemu-system-moxie qemu-system-riscv32 qemu-system-sparc qemu-system-xtensa guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 3 guest@slax:/dev/shm$ dd if=/dev/zero of=4Gb bs=1k count=4M 4194304+0 записей получено 4194304+0 записей отправлено 4294967296 байт (4,3 GB, 4,0 GiB) скопирован, 20,7155 s, 207 MB/s guest@slax:/dev/shm$ qemu-system-x86_64 -m 2000 -display sdl,gl=on -soundhw es1370 -usb -cdrom xubuntu-18.04.4-desktop-amd64.iso -enable-kvm -smp 4 -hda 4Gb WARNING: Image format was not specified for '4Gb' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions.
in just a hour I had compiled Cinelerra (by copying git tree from host BEFORE launching qemu)
Note, in such mem-restricted VM you want to use zram (not default in this ubuntu flavor): as root modprobe zram echo 1000000000 > /sys/block/zram0/disksize mkswap /dev/zram0 swapon /dev/zram0
this will create 1Gb sized compressed swap in ram
I even send email from this virtual setup, but it apparently was stuck in moderation due to size (over 750 kb).
NOW, I found something really weird! Patch as attached worked on 64-bit Ubuntu, but for my system I *must* place this call to png_set_swap(png_ptr); differently, not before png_write_info(png_ptr, info_ptr); but AFTER! I actually left both there ....
Still, this is something strange, I'll try to contact libpng author about this.....
Also, I attach my current OpenCV tweaks - trim out unneeded stuff, fixing two typos, adding -stdc++11 line for my odd system.
I still use opencv-20180401.tgz
I also have two lame (mp3lame) patches, but will send them separately. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (3)
-
Andrew Randrianasulu -
Good Guy -
Phyllis Smith