rebased on top of this )
On Tuesday, July 20, 2021, Phyllis Smith <[email protected]> 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 < > [email protected]> wrote: > >> >> >> On Monday, July 19, 2021, Andrew Randrianasulu <[email protected]> >> 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 <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Monday, July 19, 2021, Phyllis Smith <[email protected]> >>>> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Saturday, July 17, 2021, Phyllis Smith <[email protected]> >>>>>> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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. >>>>>>>>> >>>>>>>>
randrik10.tar.gz
Description: application/gzip
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
