March 2020 - Cin - Cinelerra-GG Mailing Lists

Another updated tiff patch
by Andrew Randrianasulu 16 Mar '20

16 Mar '20

This time GIMP doesn't complain about extrasamples .... sources I used today: https://it.programqa.com/question/3451806/ uint16 out[1]; out[0] = EXTRASAMPLE_ASSOCALPHA; TIFFSetField( outImage, TIFFTAG_EXTRASAMPLES, 1, &out ); and https://github.com/GNOME/gimp/blob/mainline/plug-ins/file-tiff/file-tiff-sa… But should it be associated or unassociated alpha ?

1 0

"seek fail 19, 633" on mkv
by Andrew Randrianasulu 16 Mar '20

16 Mar '20

Oh, this is me again :/ While trying just-encoded vc2 mkv in CinGG I encountered those errors/warnings: root@slax:/usr/share/cin/ffmpeg/video# cin Cinelerra Infinity - built: Mar 14 2020 01:25:13 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 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. IndexFile::draw_index: index has 0 zoom IndexFile::draw_index: index has 0 zoom IndexFile::draw_index: index has 0 zoom IndexFile::draw_index: index has 0 zoom ALSA lib confmisc.c:1281:(snd_func_refer) Unable to find definition 'defaults.pcm.dmix.channels' ALSA lib conf.c:4568:(_snd_config_evaluate) function snd_func_refer returned error: Нет такого файла или каталога ALSA lib conf.c:5036:(snd_config_expand) Args evaluate error: Нет такого файла или каталога ALSA lib pcm.c:2564:(snd_pcm_open_noupdate) Unknown PCM dmix:SB AudioALSA::open_output default: Нет такого файла или каталога FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv ** seek fail 19, 633 FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv ** seek fail 75, 2502 FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv ** seek fail 83, 2769 ** seek fail 173, 5772 ** seek fail 242, 8074 ** seek fail 2, 66 ** seek fail 4, 133 ** seek fail 5, 166 ** seek fail 6, 200 ** seek fail 7, 233 ** seek fail 9, 300 ** seek fail 10, 333 ** seek fail 11, 367 ** seek fail 12, 400 ** seek fail 14, 467 ** seek fail 15, 500 ** seek fail 16, 533 ** seek fail 17, 567 ** seek fail 19, 633 ** seek fail 20, 667 ** seek fail 21, 700 ** seek fail 22, 734 ** seek fail 24, 800 ** seek fail 25, 834 ** seek fail 26, 867 ** seek fail 27, 900 ** seek fail 29, 967 ** seek fail 30, 1001 ** seek fail 31, 1034 ** seek fail 32, 1067 ** seek fail 34, 1134 ** seek fail 35, 1167 ** seek fail 36, 1201 ** seek fail 37, 1234 ** seek fail 39, 1301 ** seek fail 40, 1334 ** seek fail 41, 1368 ** seek fail 42, 1401 ** seek fail 44, 1468 ** seek fail 45, 1501 ** seek fail 46, 1534 ** seek fail 47, 1568 ** seek fail 49, 1634 ** seek fail 50, 1668 ** seek fail 51, 1701 ** seek fail 52, 1735 ** seek fail 54, 1801 ** seek fail 55, 1835 ** seek fail 56, 1868 ** seek fail 57, 1901 ** seek fail 59, 1968 ** seek fail 60, 2002 ** seek fail 61, 2035 ** seek fail 62, 2068 ** seek fail 64, 2135 ** seek fail 65, 2168 ** seek fail 66, 2202 ** seek fail 67, 2235 ** seek fail 69, 2302 ** seek fail 70, 2335 ** seek fail 71, 2369 ** seek fail 72, 2402 ** seek fail 74, 2469 ** seek fail 75, 2502 ** seek fail 76, 2535 ** seek fail 77, 2569 ** seek fail 79, 2635 ** seek fail 80, 2669 ** seek fail 81, 2702 ** seek fail 82, 2736 ** seek fail 84, 2802 ** seek fail 85, 2836 ** seek fail 86, 2869 ** seek fail 87, 2902 ** seek fail 89, 2969 ** seek fail 90, 3003 ** seek fail 91, 3036 ** seek fail 92, 3069 ** seek fail 94, 3136 ** seek fail 95, 3169 ** seek fail 96, 3203 ** seek fail 97, 3236 ** seek fail 99, 3303 ** seek fail 100, 3336 ** seek fail 101, 3370 ** seek fail 102, 3403 ** seek fail 104, 3470 ** seek fail 105, 3503 ** seek fail 106, 3536 ** seek fail 107, 3570 ** seek fail 109, 3636 ** seek fail 110, 3670 ** seek fail 111, 3703 FFMPEG::open_decoder: some stream times estimated: /dev/shm/new_test-vc2_yuv420_8bit.mkv ** seek fail 4, 133 ** seek fail 32, 1067 ** seek fail 46, 1534 ** seek fail 60, 2002 ** seek fail 88, 2936 ** seek fail 102, 3403 ** seek fail 116, 3870 ** seek fail 157, 5238 ** seek fail 214, 7140 ** seek fail 269, 8975 ** seek fail 8, 266 ** seek fail 11, 367 ** seek fail 14, 467 ** seek fail 22, 734 ** seek fail 25, 834 ** seek fail 29, 967 ** seek fail 36, 1201 ** seek fail 39, 1301 ** seek fail 43, 1434 ** seek fail 50, 1668 ** seek fail 53, 1768 ** seek fail 57, 1901 ** seek fail 64, 2135 ** seek fail 66, 2202 ** seek fail 71, 2369 ** seek fail 78, 2602 ** seek fail 81, 2702 ** seek fail 85, 2836 ** seek fail 92, 3069 ** seek fail 95, 3169 ** seek fail 99, 3303 ** seek fail 106, 3536 ** seek fail 109, 3636 ** seek fail 113, 3770 ** seek fail 120, 4004 ** seek fail 123, 4104 ** seek fail 127, 4237 ** seek fail 134, 4471 ** seek fail 137, 4571 ** seek fail 141, 4704 ** seek fail 144, 4804 ** seek fail 148, 4938 ** seek fail 151, 5038 ** seek fail 155, 5171 ** seek fail 162, 5405 ** seek fail 165, 5505 ** seek fail 169, 5638 ** seek fail 172, 5739 ** seek fail 176, 5872 ** seek fail 179, 5972 ** seek fail 183, 6106 ** seek fail 189, 6306 ** seek fail 193, 6439 ** seek fail 197, 6573 ** seek fail 200, 6673 ** seek fail 204, 6806 ** seek fail 207, 6906 ** seek fail 211, 7040 ** seek fail 218, 7273 ** seek fail 221, 7374 ** seek fail 225, 7507 ** seek fail 228, 7607 ** seek fail 232, 7741 ** seek fail 235, 7841 ** seek fail 239, 7974 ** seek fail 246, 8208 ** seek fail 249, 8308 ** seek fail 253, 8441 ** seek fail 256, 8541 ** seek fail 260, 8675 ** seek fail 263, 8775 ** seek fail 267, 8908 ** seek fail 274, 9142 ** seek fail 277, 9242 ** seek fail 281, 9376 Session time: 0:33:20 Cpu time: user: 0:01:00.374 sys: 0:00:31.212 It seems those thumbnail generating seeks fail after first keyframe? I see first few images on timeline and then they all become black :/ Still, image in compositor is OK! Ah, and wanted to report my weird bug with single click registering as doubleclick is gone! Hopefully, it was just local glitch - no need to track this down, at least!

3 6

Upd: More findings about openEXR and libtiff
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

While my b44 patch for openEXR works, it produces nearly same 32Mb big images as uncompressed tiff.. (for rgba-float project. - correspond to documentation I cited! "Channels of type UINT or FLOAT are not compressed." so, no use in cinelerra currently? (HALF = half-float, 16-bit fp per component, IIRC) there are LOSSY subtypes of compression, DWAA/DWAB - but they are mostly for proxies and final renders where "small compression is acceptable" but they require some more parameters (compression ratio), so not for this night And my hacking on TIFFTAG_PHOTOMETRIC was *wrong* .... resulted image was treated as monochrome/1bit in GIMP .. :/ so, this hunk can be dropped. sorry. ---------- Пересланное сообщение ---------- Тема: More findings about openEXR and libtiff Дата: Понедельник 16 марта 2020 Отправитель: Andrew Randrianasulu <randrianasulu(a)gmail.com> Получатель: "Cinelerra.GG" <cin(a)lists.cinelerra-gg.org> So, I digged deeper. First, gimp source says: https://github.com/GNOME/gimp/blob/mainline/plug-ins/file-tiff/file-tiff-lo… else if (extra == 0 && ((photomet == PHOTOMETRIC_RGB && spp > 3) || /* All other color space expect 1 channel (grayscale, * palette, mask). */ (photomet != PHOTOMETRIC_RGB && spp > 1))) { /* ExtraSamples field not set, yet we have more channels than * the PhotometricInterpretation field suggests. * This should not happen as the spec clearly says "This field * must be present if there are extra samples". So the files * can be considered non-conformant. * Let's ask what to do with the channel. */ extra_message = _("Non-conformant TIFF: extra channels without 'ExtraSamples' field.") https://www.awaresystems.be/imaging/tiff/tifftags/photometricinterpretation… TIFF Tag PhotometricInterpretation IFD Image Code 262 (hex 0x0106) Name PhotometricInterpretation LibTiff name TIFFTAG_PHOTOMETRIC Type SHORT Count 1 Default None Description The color space of the image data. The specification considers these values baseline: 0 = WhiteIsZero. For bilevel and grayscale images: 0 is imaged as white. 1 = BlackIsZero. For bilevel and grayscale images: 0 is imaged as black. ------>>>>>----- 2 = RGB. RGB value of (0,0,0) represents black, and (255,255,255) represents white, assuming 8-bit components. The components are stored in the indicated order: first Red, then Green, then Blue. ------<<<<<----- 3 = Palette color. In this model, a color is described with a single component. The value of the component is used as an index into the red, green and blue curves in the ColorMap field to retrieve an RGB triplet that defines the color. When PhotometricInterpretation=3 is used, ColorMap must be present and SamplesPerPixel must be 1. 4 = Transparency Mask. This means that the image is used to define an irregularly shaped region of another image in the same TIFF file. SamplesPerPixel and BitsPerSample must be 1. PackBits compression is recommended. The 1-bits define the interior of the region; the 0-bits define the exterior of the region. These values are considered an extension: 5 = Seperated, usually CMYK. 6 = YCbCr 8 = CIE L*a*b* (see also specification supplements 1 and 2) 9 = CIE L*a*b*, alternate encoding also known as ICC L*a*b* (see also specification supplements 1 and 2) The TIFF-F specification (RFC 2301) defines: 10 = CIE L*a*b*, alternate encoding also known as ITU L*a*b*, defined in ITU-T Rec. T.42, used in the TIFF-F and TIFF-FX standard (RFC 2301). The Decode tag, if present, holds information about this particular CIE L*a*b* encoding. The DNG specification adds these definitions: 32803 = CFA (Color Filter Array) 34892 = LinearRaw LibTiff defines mostly the same values, and adds support for Pixar LogL and LogLuv encoding: PHOTOMETRIC_MINISWHITE = 0; PHOTOMETRIC_MINISBLACK = 1; PHOTOMETRIC_RGB = 2; PHOTOMETRIC_PALETTE = 3; PHOTOMETRIC_MASK = 4; PHOTOMETRIC_SEPARATED = 5; PHOTOMETRIC_YCBCR = 6; PHOTOMETRIC_CIELAB = 8; PHOTOMETRIC_ICCLAB = 9; PHOTOMETRIC_ITULAB = 10; PHOTOMETRIC_LOGL = 32844; PHOTOMETRIC_LOGLUV = 32845; So, *I think* tiff exporter shouldn't use this tag on alpha/32-bit per channel images .... if(frame->get_color_model() == BC_RGB888) // PHOTOMETRIC RGB only valid for 8-bit RGB TIFFSetField(stream, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB); currently recompiling Cin with this change .... probably additional tag needed for alpha samples ... so, not final Next into openEXR! https://en.wikipedia.org/wiki/OpenEXR B44 This form of compression is lossy for half data and stores 32-bit data uncompressed. It maintains a fixed compression size of either 2.28:1 or 4.57:1 and is designed for realtime playback. B44 compresses uniformly regardless of image content. [10] B44A An extension to B44 where areas of flat color are further compressed, such as alpha channels. Mmm.. realtime playback! https://rainboxlab.org/downloads/documents/EXR_Data_Compression.pdf says basically same thing about B44/B44A, with slightly more tech details. Added, currently compiles (see draft patch, made in analogy with my tiff patch) OpenEXR lib multithreading topic: https://lists.nongnu.org/archive/html/openexr-devel/2009-11/msg00001.html --quote--- When threading is enabled in the library, multiple scanline blocks or tiles are processed concurrently. A scanline block is 32 lines for PIZ compression. Threading doesn't kick in unless each writePixels() call supplies multiple blocks' worth of pixels. For best threading performance, write the entire image with a single writePixels() call. See also Section 7.2 of http://www.openexr.com/ReadingAndWritingImageFiles.pdf. ----quote end--- from this file ... -----****---- Multithreaded I/O The IlmImf library supports multithreaded file input and output where the library creates its own worker threads that are independent of the application program's threads. When an application thread calls readPixels(), readTiles(), writePixels() or writeTiles() to read or write multiple scan lines or tiles at once, the library's worker threads process the tiles or scanlines in parallel. During startup, the application program must enable multithreading by calling function setGlobalThreadCount(). This tells the IlmImf library how many worker threads it should create. (As a special case, setting the number of worker threads to zero reverts to single-threaded operation; reading and writing image files happens entirely in the application thread that calls the IlmImf library.) Multithreaded I/O, Multithreaded Application Program Function setGlobalThreadCount() creates a global pool of worker threads inside the IlmImf library. If an application program has multiple threads, and those threads read or write several OpenEXR files at the same time, then the worker threads must be shared among the application threads. By default each file will attempt to use the entire worker thread pool for itself. If two files are read or written simultaneously by two application threads, then it is possible that all worker threads perform I/O on behalf of one of the files, while I/O for the other file is stalled. In order to avoid this situation, the constructors for input and output file objects take an optional numThreads argument. This gives the application program more control over how many threads will be kept busy reading or writing a particular file. -----****------ sounds like something to try, using available within Cin variable about cpu count. -------------------------------------------------------

1 0

More findings about openEXR and libtiff
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

So, I digged deeper. First, gimp source says: https://github.com/GNOME/gimp/blob/mainline/plug-ins/file-tiff/file-tiff-lo… else if (extra == 0 && ((photomet == PHOTOMETRIC_RGB && spp > 3) || /* All other color space expect 1 channel (grayscale, * palette, mask). */ (photomet != PHOTOMETRIC_RGB && spp > 1))) { /* ExtraSamples field not set, yet we have more channels than * the PhotometricInterpretation field suggests. * This should not happen as the spec clearly says "This field * must be present if there are extra samples". So the files * can be considered non-conformant. * Let's ask what to do with the channel. */ extra_message = _("Non-conformant TIFF: extra channels without 'ExtraSamples' field.") https://www.awaresystems.be/imaging/tiff/tifftags/photometricinterpretation… TIFF Tag PhotometricInterpretation IFD Image Code 262 (hex 0x0106) Name PhotometricInterpretation LibTiff name TIFFTAG_PHOTOMETRIC Type SHORT Count 1 Default None Description The color space of the image data. The specification considers these values baseline: 0 = WhiteIsZero. For bilevel and grayscale images: 0 is imaged as white. 1 = BlackIsZero. For bilevel and grayscale images: 0 is imaged as black. ------>>>>>----- 2 = RGB. RGB value of (0,0,0) represents black, and (255,255,255) represents white, assuming 8-bit components. The components are stored in the indicated order: first Red, then Green, then Blue. ------<<<<<----- 3 = Palette color. In this model, a color is described with a single component. The value of the component is used as an index into the red, green and blue curves in the ColorMap field to retrieve an RGB triplet that defines the color. When PhotometricInterpretation=3 is used, ColorMap must be present and SamplesPerPixel must be 1. 4 = Transparency Mask. This means that the image is used to define an irregularly shaped region of another image in the same TIFF file. SamplesPerPixel and BitsPerSample must be 1. PackBits compression is recommended. The 1-bits define the interior of the region; the 0-bits define the exterior of the region. These values are considered an extension: 5 = Seperated, usually CMYK. 6 = YCbCr 8 = CIE L*a*b* (see also specification supplements 1 and 2) 9 = CIE L*a*b*, alternate encoding also known as ICC L*a*b* (see also specification supplements 1 and 2) The TIFF-F specification (RFC 2301) defines: 10 = CIE L*a*b*, alternate encoding also known as ITU L*a*b*, defined in ITU-T Rec. T.42, used in the TIFF-F and TIFF-FX standard (RFC 2301). The Decode tag, if present, holds information about this particular CIE L*a*b* encoding. The DNG specification adds these definitions: 32803 = CFA (Color Filter Array) 34892 = LinearRaw LibTiff defines mostly the same values, and adds support for Pixar LogL and LogLuv encoding: PHOTOMETRIC_MINISWHITE = 0; PHOTOMETRIC_MINISBLACK = 1; PHOTOMETRIC_RGB = 2; PHOTOMETRIC_PALETTE = 3; PHOTOMETRIC_MASK = 4; PHOTOMETRIC_SEPARATED = 5; PHOTOMETRIC_YCBCR = 6; PHOTOMETRIC_CIELAB = 8; PHOTOMETRIC_ICCLAB = 9; PHOTOMETRIC_ITULAB = 10; PHOTOMETRIC_LOGL = 32844; PHOTOMETRIC_LOGLUV = 32845; So, *I think* tiff exporter shouldn't use this tag on alpha/32-bit per channel images .... if(frame->get_color_model() == BC_RGB888) // PHOTOMETRIC RGB only valid for 8-bit RGB TIFFSetField(stream, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB); currently recompiling Cin with this change .... probably additional tag needed for alpha samples ... so, not final Next into openEXR! https://en.wikipedia.org/wiki/OpenEXR B44 This form of compression is lossy for half data and stores 32-bit data uncompressed. It maintains a fixed compression size of either 2.28:1 or 4.57:1 and is designed for realtime playback. B44 compresses uniformly regardless of image content. [10] B44A An extension to B44 where areas of flat color are further compressed, such as alpha channels. Mmm.. realtime playback! https://rainboxlab.org/downloads/documents/EXR_Data_Compression.pdf says basically same thing about B44/B44A, with slightly more tech details. Added, currently compiles (see draft patch, made in analogy with my tiff patch) OpenEXR lib multithreading topic: https://lists.nongnu.org/archive/html/openexr-devel/2009-11/msg00001.html --quote--- When threading is enabled in the library, multiple scanline blocks or tiles are processed concurrently. A scanline block is 32 lines for PIZ compression. Threading doesn't kick in unless each writePixels() call supplies multiple blocks' worth of pixels. For best threading performance, write the entire image with a single writePixels() call. See also Section 7.2 of http://www.openexr.com/ReadingAndWritingImageFiles.pdf. ----quote end--- from this file ... -----****---- Multithreaded I/O The IlmImf library supports multithreaded file input and output where the library creates its own worker threads that are independent of the application program's threads. When an application thread calls readPixels(), readTiles(), writePixels() or writeTiles() to read or write multiple scan lines or tiles at once, the library's worker threads process the tiles or scanlines in parallel. During startup, the application program must enable multithreading by calling function setGlobalThreadCount(). This tells the IlmImf library how many worker threads it should create. (As a special case, setting the number of worker threads to zero reverts to single-threaded operation; reading and writing image files happens entirely in the application thread that calls the IlmImf library.) Multithreaded I/O, Multithreaded Application Program Function setGlobalThreadCount() creates a global pool of worker threads inside the IlmImf library. If an application program has multiple threads, and those threads read or write several OpenEXR files at the same time, then the worker threads must be shared among the application threads. By default each file will attempt to use the entire worker thread pool for itself. If two files are read or written simultaneously by two application threads, then it is possible that all worker threads perform I/O on behalf of one of the files, while I/O for the other file is stalled. In order to avoid this situation, the constructors for input and output file objects take an optional numThreads argument. This gives the application program more control over how many threads will be kept busy reading or writing a particular file. -----****------ sounds like something to try, using available within Cin variable about cpu count.

1 0

OGG validation?
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

I recall some strangeness with recently re-added OGG/theora output. I found this comment in old CinCV repo: https://repo.or.cz/cinelerra_cv/ct.git/commit/5d7c9bfd9dbfa3c4ae673a8c8b3d3… "r636: j^'s (j(a)v2v.cc) patch to mux ogg in a way compilant with specification y - makes oggz-validate happy and probably some players also" I followed app name and landed here: https://www.xiph.org/oggz/ Oggz Oggz comprises liboggz and the tool oggz, which provides commands to inspect, edit and validate Ogg files. The oggz-chop tool can also be used to serve time ranges of Ogg media over HTTP by any web server that supports CGI. liboggz is a C library for reading and writing Ogg files and streams. It offers various improvements over the reference libogg, including support for seeking, validation and timestamp interpretation. Download The latest version is 1.1.1, released Apr 29 2010. http://git.xiph.org/?p=liboggz.git;a=shortlog git has some improvements over it .... I hope it will helpful in catching those strange errors about not marked keyframes ...

2 2

vmodule.c and caching of decoded video?
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

Question: I was looking at old CinCV repo and found there this commit: https://repo.or.cz/cinelerra_cv/ct.git/commit/1be2d5c765349982fa1d9b72bdcaa… r743: Enable caching of frames even when not rendering static frames diff --git a/cinelerra/vmodule.C b/cinelerra/vmodule.C index 65efb0a..841fb40 100644 (file) --- a/cinelerra/vmodule.C +++ b/cinelerra/vmodule.C @@ -235,12 +235,12 @@ SET_TRACE // file -> temp // Cache for single frame only - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(1); SET_TRACE result = source->read_frame((*input)); SET_TRACE - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(0); //printf("VModule::import_frame 1 %lld %f\n", input_position, frame_rate); @@ -306,10 +306,10 @@ SET_TRACE { //printf("VModule::import_frame 30 %p\n", output); // Cache single frames only - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(1); result = source->read_frame(output); - if(renderengine && renderengine->command->single_frame()) +// if(renderengine && renderengine->command->single_frame()) source->set_cache_frames(0); //printf("VModule::import_frame 40\n"); } cehtehs branch of CinelerraCV in modern CinGG same function done a bit differently, but still only enables caching of single frames. Why? https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerr… 292 int use_cache = renderengine && 293 renderengine->command->single_frame(); search for more instances of use_cache .... Of course there might be some bug somewhere preventing such usage - but I really like to see this commented, then ... Ah, it was disabled again in https://repo.or.cz/cinelerra_cv/ct.git/commit/c8d7b9183ac263d540ccbc15b125f… (part of big 2.1 merge) I wonder what will hapen if I enable this .. :} Something else to try .... As far as I understand, anync decoding by itself also disabled in CinGG, looking at same module? But even normal decoding still may leave few frames around, and Cin may reuse them, for example for backward playback, no? Having some clarification about what each mode was supposed to do at the top of file will be great .... Unfortunately, I don't understand Cin enough for making those top comments.. I think. This idea obviously can be low priority - just add new module comment each time you edited said module ..so, after some time thwy all will contain brief description of their functions and quircks/historical artifacts, I think PS; I spend a lot of time trying to debug this bc2000 playback crash - so yes, threading is not as simple in impl as I made it on (virtual) paper .. :/

3 2

Today's GIT checkin includes 18 new Shape Wipe video transitions
by Phyllis Smith 15 Mar '20

15 Mar '20

Rafa created 15 new Shape Wipe video transitions + 3 Cinelerra new shape wipes. Some are pretty cool and I like Rare Spiral and Star. The other big thing is BT #375 for the first bug which is Open EDL level backups which I will explain in that BT once I get around to it. Phyllis/GG

5 5

filetiff patch
by Andrew Randrianasulu 15 Mar '20

15 Mar '20

I tried few more compression schemas from libtiff 4.0.10 tiff.h: #define TIFFTAG_COMPRESSION 259 /* data compression technique */ #define COMPRESSION_NONE 1 /* dump mode */ #define COMPRESSION_CCITTRLE 2 /* CCITT modified Huffman RLE */ #define COMPRESSION_CCITTFAX3 3 /* CCITT Group 3 fax encoding */ #define COMPRESSION_CCITT_T4 3 /* CCITT T.4 (TIFF 6 name) */ #define COMPRESSION_CCITTFAX4 4 /* CCITT Group 4 fax encoding */ #define COMPRESSION_CCITT_T6 4 /* CCITT T.6 (TIFF 6 name) */ #define COMPRESSION_LZW 5 /* Lempel-Ziv & Welch */ #define COMPRESSION_OJPEG 6 /* !6.0 JPEG */ #define COMPRESSION_JPEG 7 /* %JPEG DCT compression */ #define COMPRESSION_T85 9 /* !TIFF/FX T.85 JBIG compression */ #define COMPRESSION_T43 10 /* !TIFF/FX T.43 colour by layered JBIG compression */ #define COMPRESSION_NEXT 32766 /* NeXT 2-bit RLE */ #define COMPRESSION_CCITTRLEW 32771 /* #1 w/ word alignment */ #define COMPRESSION_PACKBITS 32773 /* Macintosh RLE */ #define COMPRESSION_THUNDERSCAN 32809 /* ThunderScan RLE */ /* codes 32895-32898 are reserved for ANSI IT8 TIFF/IT <dkelly(a)apago.com) */ #define COMPRESSION_IT8CTPAD 32895 /* IT8 CT w/padding */ #define COMPRESSION_IT8LW 32896 /* IT8 Linework RLE */ #define COMPRESSION_IT8MP 32897 /* IT8 Monochrome picture */ #define COMPRESSION_IT8BL 32898 /* IT8 Binary line art */ /* compression codes 32908-32911 are reserved for Pixar */ #define COMPRESSION_PIXARFILM 32908 /* Pixar companded 10bit LZW */ #define COMPRESSION_PIXARLOG 32909 /* Pixar companded 11bit ZIP */ #define COMPRESSION_DEFLATE 32946 /* Deflate compression */ #define COMPRESSION_ADOBE_DEFLATE 8 /* Deflate compression, as recognized by Adobe */ /* compression code 32947 is reserved for Oceana Matrix <dev(a)oceana.com> */ #define COMPRESSION_DCS 32947 /* Kodak DCS encoding */ #define COMPRESSION_JBIG 34661 /* ISO JBIG */ #define COMPRESSION_SGILOG 34676 /* SGI Log Luminance RLE */ #define COMPRESSION_SGILOG24 34677 /* SGI Log 24-bit packed */ #define COMPRESSION_JP2000 34712 /* Leadtools JPEG2000 */ #define COMPRESSION_LERC 34887 /* ESRI Lerc codec: https://github.com/Esri/lerc */ /* compression codes 34887-34889 are reserved for ESRI */ #define COMPRESSION_LZMA 34925 /* LZMA2 */ #define COMPRESSION_ZSTD 50000 /* ZSTD: WARNING not registered in Adobe-maintained registry */ #define COMPRESSION_WEBP 50001 /* WEBP: WARNING not registered in Adobe-maintained registry */ Sadly, only deflate worked with 32-bit floating point session. Others complained like FileTIFF: Compression scheme 32908 scanline encoding is not implemented. Also, GIMP complained a bit, but allow me to open image anyway: tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. tiff_io_warning: [TIFFReadDirectory] Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples. bps: 32 load_contiguous bytes_per_pixel: 16, format: 16 Probably for other compression schemas differet, non-scanline method of calling libtiff must be used? Also, a bit of nipicking (?) but Cinelerra doesn' show single-frame rendering correctly in stats: ** rendered 0 frames in 14.170 secs, 0.000 fps Render::render_single: Session finished. ** rendered 355 frames in 249.619 secs, 1.422 fps Render::render_single: Session finished. ** rendered 0 frames in 3.640 secs, 0.000 fps Shouldn't it be 1 frame, at least?

1 0

Wordpress website
by Olivier Humbert 14 Mar '20

14 Mar '20

Hi there. That was a long time I didn't received any notification from the cin-gg wordpress (probably around 2 or 3 months). Then, I logged in to check by myself if there was really no new translation update to do. I found some and did those, so French translation is back to 100% there. Just leaving this email here because something looks wrong with the notification system. Also, I'd encourage other language translators to logged in and check s well if that's a while they didn't receveid a notifcation too. Hope that helps. Olivier -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK

3 9

HAP codec, VC2 (dirac) encoder in ffmpeg tests
by Andrew Randrianasulu 14 Mar '20

14 Mar '20

Hello! Sorry if I push too many mails with questionable ideas, but ... I recently was reading phoronix, Michael put up this article: https://www.phoronix.com/scan.php?page=news_item&px=New-High-Quality-GPU-Co… "Written by Michael Larabel in Standards on 9 March 2020 at 09:50 AM EDT. 20 Comments STANDARDS -- Compression experts Rich Geldreich and Stephanie Hurlburt with their Binomial consulting firm are about to release a high-quality open-source compression codec for GPUs." This made me think, because I already saw something along those lines.... https://vdmx.vidvox.net/blog/hap --quote-- When should I use Hap? Will my hardware support Hap? For most realtime video projects, traditional CPU-based codecs such as Photo-JPEG or the Apple Intermediate Codec offer a reasonable tradeoff between image quality, CPU use and file size. However, when you need to play back a lot of movies at once — particularly if they are high-res — the CPU load may exceed the limits of your processors. These situations are where highly optimized codecs (like Hap) are most useful. On the Mac you will need to be running 10.6.8 or later, on PC Vista or newer — you don't need a super-fast computer, but you do need a fast drive for playback (preferably an SSD). --quote end--- basically, high-datarate codec based on DXT compression + libsnappy. In theory ffmpeg should be able to encode it, if compiled with such library, I compiled system ffmpeg with this option: -- --enable-libsnappy but CinGG's copy of ffmpeg still compiles with default, no. On next rebuild I'll try this option. At least I can encode such file with ffmpeg -i ~/0005.avi -c:v hap -c:a copy /dev/shm/HAP.mov and result viewable in CinGG (but not OpenGL accelerated, iiuc) command line from https://gist.github.com/dlublin/e4585b872dd136ae88b2aa51a6a89aac ("Encoding to Hap from the command line using FFmpeg") But then I tried vc2 encoder, in both qt and mkv containers, and while CinGG compiled with ffmpeg git was able to open this file, it failed with both old ffplay and new (as in, compiled few days ago with recent ffmpeg) mpalyer :/ So, probably not very useful ... I also tried to switch various format options, but for both qt and mkv Cin was saying: no format named: mkv so, may be some mapping between Cin internal "formats" and ffmpeg still off.

1 0