July 2021 - Cin - Cinelerra-GG Mailing Lists

[patch] try to use pkg-config in cinelerra/Makefile
by Andrew Randrianasulu 20 Jul '21

20 Jul '21

for handling termux-specific x11 path w/o hardcoding it... can anyone test on normal Linux?

2 2

x265 multilib git patch + 2 updated h265 high bit depth profiles
by Andrew Randrianasulu 20 Jul '21

20 Jul '21

tested on my arm tablet, seems to work for small (352*288 25 fps) video

2 1

Re: [Cin] "color hell"
by Andrew Randrianasulu 20 Jul '21

20 Jul '21

rebased on top of this ) On Tuesday, July 20, 2021, Phyllis Smith <phylsmith2017(a)gmail.com> wrote: > These changes as provided by Andrew have been checked into GIT (finally! > finished testing and checking): > > 0003-Attempt-at-differenciating-601-pal-and-ntsc.patch > 0004-Fix-yuv_color_space-menu-after-adding-bt601-variants.patch > 0005-Add-comment-about-order-of-array-entries-for-yuv_col.patch > 0006-Forgot-to-alter-colorspace-plugin-for-bt2020-split.patch > 0006-Slightly-enlarge-colirspace-menu-width.patch > 0007-Attempt-at-differenciating-bt2020-ncl-vs-bt2020-cl.patch > 0056-Add-simple-validation-for-yuv_color_space-prevent-cr.patch > 0057-Add-two-more-checks-for-Cinelerra_rc-loading.patch > > Or in randrik9 tar from Jul 17th: > > 0041-Attempt-at-differenciating-601-pal-and-ntsc.patch > 0042-Fix-yuv_color_space-menu-after-adding-bt601-variants.patch > 0043-Add-comment-about-order-of-array-entries-for-yuv_col.patch > 0044-Slightly-enlarge-colirspace-menu-width.patch > 0045-Attempt-at-differenciating-bt2020-ncl-vs-bt2020-cl.patch > 0046-Forgot-to-alter-colorspace-plugin-for-bt2020-split.patch > + > + > > > > > > On Sun, Jul 18, 2021 at 5:20 PM Andrew Randrianasulu < > randrianasulu(a)gmail.com> wrote: > >> >> >> On Monday, July 19, 2021, Andrew Randrianasulu <randrianasulu(a)gmail.com> >> wrote: >> >>> try this patch, it should preven crash in patched cin if you manually or >>> programmatically set yuv_color_space to number cin does not recognize (but >>> I am afraid iriginal cingg also can be crashed by just manually editing >>> Cinelerra_rc and setting this (or even some similar) line to wrong value.. >>> some generic validation pass nedded for preventing this..) >> >> >> >> two more checks for color range and vicon colors... apply on top of 0056 >> (I forgot to decrement index by 1 so it was not crashing on yuv_color_space >> 5, but this was illegal value) >> >> if this specific vulnerability not mentioned yet in manul - I think it >> deserves line or two.. (randomly editing Cinelerra_rc easily result in >> crash at access...) >> >> >> >>> On Monday, July 19, 2021, Andrew Randrianasulu <randrianasulu(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Monday, July 19, 2021, Phyllis Smith <phylsmith2017(a)gmail.com> >>>> wrote: >>>> >>>>> More testing of "color hell" has been completed here >>>>> I "think" that I have tested enough to check this into GIT, as long as >>>>> users can tolerate the following that have workarounds: >>>>> There are 2 problems that occur when going back to a previous >>>>> Cinelerra version: >>>>> 1) if you set YUV Color Space to 601_PAL and save settings and then >>>>> load in a previous version, it crashes. >>>>> >>>> >>>> ow, this is bad ( >>>> >>>> probably this array I expanded in patch overflows... >>>> >>>> >>>>> 2) if you set YUV Color Space to 2020_CL and save settings and then >>>>> load in a previous version, the Color Space will report either "Low" or >>>>> "JPEG" >>>>> >>>> >>>> >>>> hm, something steps on someone's else toes.. >>>> >>>> not sure if it really desirable to merge in such state, may be I'll >>>> find way to move few fields around first.. >>>> >>>>> >>>>> On Sat, Jul 17, 2021 at 12:47 PM Andrew Randrianasulu < >>>>> randrianasulu(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Saturday, July 17, 2021, Phyllis Smith <phylsmith2017(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Andrew, >>>>>>> Sorry but I have not found any difference between 601 Pal and 601 >>>>>>> NTSC other than what ffprobe reports. The video looks 100% identical. >>>>>>> Perhaps I am doing something wrong. Here is what I did: >>>>>>> >>>>>>> 1) downloaded Cows 4k.webm (do not remember exact name) >>>>>>> 2) deleted most of it so it does not take so long to render >>>>>>> 3) set Format to YUV-8 >>>>>>> 4) set Preferences/Appearances/YUV color space to 601 NTSC >>>>>>> 5) render using h2674.mp4 >>>>>>> ...6) Then reloaded shortened Cows, set Format to YUV-8 and color >>>>>>> space to 601 PAL, rendered. >>>>>>> 7) ran ydiff on the 2 output videos and the result is that the video >>>>>>> is 100% the same >>>>>>> 8) ffprobe does report smpte170m (for NTSC) ersus bt470bg (for PAL) >>>>>>> >>>>>>> So I am either doing something wrong, or splitting 601 and 2020 is >>>>>>> just not relevant. I have to do another 2020 split test yet. >>>>>>> >>>>>> >>>>>> may be player/nle supposed to alter video depending on those tags? so >>>>>> it will be visible not in encoded file but after full decoding + display IF >>>>>> player reacts correctly to those attribs (many do not care) >>>>>> >>>>>> >>>>>>> Also, when I load one of the output files in a previous version of >>>>>>> Cinelerra without the mod, the Color Space comes up as "low" -- where that >>>>>>> came from I have no idea. >>>>>>> >>>>>> >>>>>> >>>>>> i altered not just encoding part but also decoding/internal >>>>>> colorspace conversion paths - because original code does so... so different >>>>>> reactions to same input kinda expected? >>>>>> >>>>>> may be you can put my patches in separate branch, incl. other >>>>>> 'staging' patches (termux, h265-multilib, exr batchrender...)? so they will >>>>>> be available easily yet not interfere with main branch yet... >>>>>> >>>>>> >>>>>> >>>>>>> On Wed, Jul 14, 2021 at 12:47 PM Andrew Randrianasulu < >>>>>>> randrianasulu(a)gmail.com> wrote: >>>>>>> >>>>>>>> I made those commits into new series, you probably want to rename >>>>>>>> this to 0009-*.patch... I do not think old 0008 patch will do any good - >>>>>>>> GReen-BLue-REd planar float format is not something Cin easily can convert >>>>>>>> for internal use (I saw similar comment in oiio sources... I am not good >>>>>>>> enough for adding even simple format to ffmpeg/swscale.. even with already >>>>>>>> written examples) >>>>>>>> >>>>>>>> from >>>>>>>> >>>>>>>> https://github.com/OpenImageIO/oiio/blob/master/src/ffmpeg.imageio/ >>>>>>>> ffmpeginput.cpp >>>>>>>> >>>>>>>> case AV_PIX_FMT_GBRPF32BE: >>>>>>>> case AV_PIX_FMT_GBRPF32LE: >>>>>>>> nchannels = 3; >>>>>>>> datatype = TypeFloat; >>>>>>>> m_dst_pix_format = AV_PIX_FMT_RGB48; // ? AV_PIX_FMT_GBRPF32 >>>>>>>> // FIXME: They don't have a type for RGB float, only GBR >>>>>>>> float. >>>>>>>> // Yuck. Punt for now and save as uint16 RGB. If people >>>>>>>> care, we >>>>>>>> // can return and ask for GBR float and swap order. >>>>>>>> break; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, July 14, 2021, Andrea paz < >>>>>>>> gamberucci.andrea(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> I tried to compile with the two patches 0007 and 0008, but the >>>>>>>>> compilation gives an error. I append the cin5.log, if it helps. >>>>>>>>> >>>>>>>>

1 0

my rendering is really slow
by gorge rankin 18 Jul '21

18 Jul '21

Hello, I've not done many renders since I'm learning. Well I made a project. It was slow. Really slow. My media: from OBS, 60fps, yuv, bt.709, 15 seconds long, 1440p. I've told cin to use yuv444p with the presets so colors match up. project is using format YUVA-8 Bit. it takes me 3 minutes to render and I've only pasted the clip and said render and use the h264/nvenc preset. so to be clear I'm just re-rendering a video, no edits nothing! I've tried many of the other presets. My computer is an i5 skylake with 16 gig of ram, ubuntu 21.04 using 6053512f2d26fbc13432632eeaa52017 cin_for_newer_distros.AppImage for comparisons sake, the same video in shotcut renders in 3 seconds with nvenc. Any thoughts? Thank you for any help you can provide.

4 18

cpu debug patch for Andrea
by Andrew Randrianasulu 17 Jul '21

17 Jul '21

Andrea, can yo apply thus patch, load/play/encode file with this patch applied and post output? for me it prints twice "1" and then consistently "8" (my num. of cores)

2 4

Re: [Cin] "color hell"
by Andrew Randrianasulu 17 Jul '21

17 Jul '21

On Tuesday, July 13, 2021, Phyllis Smith <phylsmith2017(a)gmail.com> wrote: > Andrew, I really like the "color hell" moniker. > Andrea, you are right, ffprobe shows it correctly. I had always heard > that mediainfo sometimes got it wrong, but this is the first time I saw > that. > > What about old projects? will they handle this change correctly? > I tried to add my new colorspace as numbered define _after_ all pre-used defines, while renaming old bt601 to bt601 ntsc (given usual ntsc-centered preference in other parts of cin) and of course _order_ in preferences mattered, my patches made things shift down by one (so displayed colorspace and encoded colorspace drifted by one! bt2020 displayed was real bt601 pal... bt601 ntsc was bt709... as you sharply noted!) I think we save it per-session (in Cinelerra_rc) not per-project? will look more into it... try add two more patches I attached? one is fix another is comment. Also, while we are here may be rename and enlarge bt2020 label for bt2020 *nc* as code (in ffmpeg.C) seems to map it really? > On Tue, Jul 13, 2021 at 12:17 PM Andrew Randrianasulu < > randrianasulu(a)gmail.com> wrote: > >> >> >> On Tuesday, July 13, 2021, Phyllis Smith via Cin < >> cin(a)lists.cinelerra-gg.org> wrote: >> >>> Not so sure about that after running more tests. >>> Using 601Pal, mediainfo reports BT.601. >>> Using 601Ntsc, medinao reports BT.709 !! >>> As always, have to make sure old projects still work. >>> >> >> >> its called color hell for this exact reason) >> >> may be mediainfo a bit wrong (at least ver. you used - shoukd be recent >> on Fedora, but small fixes like this can go in anytime...) >> >> see confusing code at (should be recent enough from 2020) >> >> https://sourceforge.net/p/mediainfo/discussion/297610/ >> thread/0b6d2fd38f/?limit=25 >> >> ===== >> >> ha. >> >> //---------------------------------------------------------- >> ----------------- >> extern const char* Mpegv_colour_primaries(int8u colour_primaries) >> { >> switch (colour_primaries) >> { >> case 1 : return "BT.709"; >> case 4 : return "BT.470 System M"; >> case 5 : return "BT.601 PAL"; >> case 6 : return "BT.601 NTSC"; >> case 7 : return "SMPTE 240M"; //Same as BT.601 NTSC >> case 8 : return "Generic film"; >> case 9 : return "BT.2020"; //Added in HEVC >> case 10 : return "XYZ"; //Added in HEVC 2014 >> case 11 : return "DCI P3"; //Added in HEVC 2016 >> case 12 : return "Display P3"; //Added in HEVC 2016 >> case 22 : return "EBU Tech 3213"; //Added in HEVC 2016 >> default : return ""; >> } >> } >> >> //---------------------------------------------------------- >> ----------------- >> extern const char* Mpegv_transfer_characteristics(int8u >> transfer_characteristics) >> { >> switch (transfer_characteristics) >> { >> case 1 : return "BT.709"; //Same as BT.601 >> case 4 : return "BT.470 System M"; >> case 5 : return "BT.470 System B/G"; >> case 6 : return "BT.601"; >> case 7 : return "SMPTE 240M"; >> case 8 : return "Linear"; >> case 9 : return "Logarithmic (100:1)"; //Added in MPEG-4 Visual >> case 10 : return "Logarithmic (316.22777:1)"; //Added in MPEG-4 >> Visual >> case 11 : return "xvYCC"; //Added in AVC >> case 12 : return "BT.1361"; //Added in AVC >> case 13 : return "sRGB/sYCC"; //Added in HEVC >> case 14 : return "BT.2020 (10-bit)"; //Same a BT.601 //Added in >> HEVC, 10/12-bit difference is in ISO 23001-8 >> case 15 : return "BT.2020 (12-bit)"; //Same a BT.601 //Added in >> HEVC, 10/12-bit difference is in ISO 23001-8 >> case 16 : return "PQ"; //Added in HEVC 2015 >> case 17 : return "SMPTE 428M"; //Added in HEVC 2015 >> case 18 : return "HLG"; //Added in HEVC 2016 >> default : return ""; >> } >> } >> >> //---------------------------------------------------------- >> ----------------- >> extern const char* Mpegv_matrix_coefficients(int8u matrix_coefficients) >> { >> switch (matrix_coefficients) >> { >> case 0 : return "Identity"; //Added in AVC >> case 1 : return "BT.709"; >> case 4 : return "FCC 73.682"; >> case 5 : return "BT.470 System B/G"; >> case 6 : return "BT.601"; //Same as BT.470 System B/G >> case 7 : return "SMPTE 240M"; >> case 8 : return "YCgCo"; //Added in AVC >> case 9 : return "BT.2020 non-constant"; //Added in HEVC >> case 10 : return "BT.2020 constant"; //Added in HEVC >> case 11 : return "Y'D'zD'x"; //Added in HEVC 2016 >> case 12 : return "Chromaticity-derived non-constant"; //Added in >> HEVC 2016 >> case 13 : return "Chromaticity-derived constant"; //Added in HEVC >> 2016 >> case 14 : return "ICtCp"; //Added in HEVC 2016 >> default : return ""; >> } >> } >> >> ===== >> >> note _transfer characteristics_ #1 said to be the same for bt. 709 and >> #6 bt. 601! (in comment) >> >> can you post full mediainfo output for input video, and three other >> videos: unmodded Cin, modded and set to BT601 NTSC, set to BT601 pal? >> >> >>> >>> On Mon, Jul 12, 2021 at 2:26 PM Andrew Randrianasulu via Cin < >>> cin(a)lists.cinelerra-gg.org> wrote: >>> >>>> According to >>>> >>>> https://kdenlive.org/en/project/color-hell-ffmpeg- >>>> transcoding-and-preserving-bt-601/ >>>> >>>> bt 601 pal and bt 601 ntsc are slightly different, I tried to update >>>> CinGG's definitions so now she have two distinct 601 colorspaces, but I >>>> still can be wrong (esp on kr, kb coeffecients) >>>> >>>> can anyone test patch 3 and see if it makes any positive difference? >>>> >>>> >>>> -- >>>> Cin mailing list >>>> Cin(a)lists.cinelerra-gg.org >>>> https://lists.cinelerra-gg.org/mailman/listinfo/cin >>>> >>>

2 7

exportEDL, timecode patches
by Andrew Randrianasulu 17 Jul '21

17 Jul '21

I think I enabled _writing_ timecode info into rendered files (tested mxf) if you set timecode for your timeline manually - it should be respected. If you render selection of your timeline - timecode will be set at start timecode of your render position. if you render selection with already altered (via clapping icon) timeline - it also should work. I found you (sometimes?) need to hit 'align timecodes' menu item for refreshing asset timecode info.... but such action will mes up timeline if some assets had no real timecode info.... Anyway, try to test those patches and told us how useful (or dangerous?) they are... In theory I think this is good idea to get embedded timecodes into rendered files (rel. to your working timeline) , but may be you sometimes want zeroed tc in output files?

3 18

zscale plugin
by Andrea paz 16 Jul '21

16 Jul '21

I wanted to try the "zscale" plugin of ffmpeg (inside CinGG, of course). I installed the zimg library and now I need to configure FFmpeg with --enable-libzimg. How can I do this? https://ffmpeg.org/ffmpeg-filters.html#zscale-1 https://github.com/FFmpeg/FFmpeg/commit/416e35e5aafc2a2bf77372d5e8479c28796…

3 8

"color hell"
by Andrew Randrianasulu 13 Jul '21

13 Jul '21

According to https://kdenlive.org/en/project/color-hell-ffmpeg-transcoding-and-preservin… bt 601 pal and bt 601 ntsc are slightly different, I tried to update CinGG's definitions so now she have two distinct 601 colorspaces, but I still can be wrong (esp on kr, kb coeffecients) can anyone test patch 3 and see if it makes any positive difference?

3 8

"workaround_bugs=1" for ffmpeg decode
by Andrew Randrianasulu 11 Jul '21

11 Jul '21

I run into some cool but unwanted image distortion while playing back and forth sample file ~/matrixbench_highdivx_ac3.avi from samples.mplayerhq.hu sadly, setting this avctx flag doesn't fix artefacts, but I send it out anyway because someone might run into buggy early encode requiring this workaround variable to be set... I think you also can set it via opts file, but not tested this (because for me workaround does not improve image quality after few fast forward/fast backwards)

1 0