On Tuesday, July 20, 2021, Phyllis Smith <phylsmith2017@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@gmail.com> wrote:

On Monday, July 19, 2021, Andrew Randrianasulu <randrianasulu@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@gmail.com> wrote:

On Monday, July 19, 2021, Phyllis Smith <phylsmith2017@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@gmail.com> wrote:

On Saturday, July 17, 2021, Phyllis Smith <phylsmith2017@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@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@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.