Crazy family JPEG formats (2017).

[Jamaika]

Jamaik's errors in codec development.
Is the av01/dav1d/gav1 decoder the same?
I thought it was about some specialized photos, films of some equipment. I was wrong. All decoders should decode aom movies.
Why so many set-top boxes? The decoders seem to have complicated config.
Aom decoder without assember doesn't exist. I didn't manage to configure it.
The dav1d decoder is used in ffplay. Strange that not the original aom decoder, but in this way I saw that it must work in GCC.
The dav1d decoder has downside. It can't decode all types of aom/avif 8/16bit files. One decoder for the specified bit depth value.

[foxyshadis]

libaom initially couldn't be built in ffmpeg because of symbol conflicts with libvpx, which it grew out of, but it was also obnoxiously slow and saddled with the legacy of a development framework that went all the way back to VP6.2. dav1d started from scratch to implement a decoder in the most optimized possible way, and mostly succeeded though it took longer than expected, especially for arm which is where most of their attention is going; gav1 is Google's infuriating Not Invented Here syndrome rearing its head again, they refuse to get onboard with anything for long if they don't own the entire project. gav1 is roughly where dav1d was about two years ago, I'd say, though benchmarks are probably better by now.

Within their limits, they all decode video exactly the same way. Their use in AVIF is only because they can decompress any AV1 images (still or otherwise) in the file.

[Marsu42]

Originally Posted by foxyshadis

gav1 is Google's infuriating Not Invented Here syndrome rearing its head again, they refuse to get onboard with anything for long if they don't own the entire project

Were there comments from Google as to why they chose to develop their own decoder, and/or what's their goal by "owning" the project (as they are free to fork oss if things go wrong)?

It's not like Google is completely self-centered, after all they put vp10 into the av1 alliance. Not defending Google here, they're way beyond "do no evil", just wondering.

Originally Posted by foxyshadis

Within their limits, they all decode video exactly the same way. Their use in AVIF is only because they can decompress any AV1 images (still or otherwise) in the file.

I faintly remember there were differences decoding "real" rgb-lossless avif files concerning color space, but I didn't track this anymore lately - and maybe these are not problems of the core decoder lib, but the implementation in libheif/libavif or even higher up like in a web browser.

I have added some libavif bug tickets because I really couldn't pinpoint it - but try rgb-lossless encode-decode a colour wheel (try with,without alpha) in your favorite app.

[Jamaika]

New codecs 18/12/2020

J P E G   \/ |
          /\ |_   e n c o d e r    [0.1.0-d11752ff Supported/generated: Scalar]
Library:          brotli        1.0.9         c   [24 Sep 2020] {addition google}
                  brunsli       JXL           c++ [17 Dec 2020] {addition google}
                  butteraugli   JXL           c++ [01 Dec 2020] {addition google}
                  highway       0.1           c++ [09 Dec 2020] {addition google}
                  skcms                       c++ [07 Feb 2020] {addition google}
                  libsJPEG      0.1.0         c++ [03 Mar 2020] {addition google}
                  libJPEG-turbo 2.0.91  8bit  c   [07 Dec 2020]
                  lodePNG                     c++ [17 Oct 2020]
                   libPNG       1.6.38        c   [24 May 2020] {for APNG}
                   giflib       5.2.1         c   [24 Jun 2019]
                     zlib       1.2.11.1      c   [17 Sep 2020]
                  openexr       2.5.99        c++ [02 Dec 2020] {instead TIFF, Adobe DNG}
                    Imath       3.0.0         c++ [17 Dec 2020] {addition openexr}
Compiled by Jamaika

VVCSoftware: VTM Encoder Version 11.0-9d3f3afa [Windows][GCC 10.2.1][64 bit] [SIMD=NONE]
VVCSoftware: HDRTools Version 0.20-0db34fbc

Library:          libheif/avif  1.9.1-667eeab  8<>12b c++ [16 Dec 2020]
                  x265          3.4+30 8<>12b c++ [11 Dec 2020]
                  libde265      1.0.8  8<>12b c++ [02 Nov 2020]
                  libaom        2.0.1         c   [17 Dec 2020]
                  libda1vd      0.8.0         c   [16 Dec 2020]
                  libJPEG-turbo 2.0.91  8bit  c   [07 Dec 2020]
                  libPNG        1.6.38        c   [24 May 2020]
                    zlib        1.2.11.1      c   [17 Sep 2020]

libheif doesn't include the latest internal libavif 0.8.4.1 version

Library:          libWebP2      0.0.1-c13f92d  8<>12b c++ [17 Dec 2020] {10<>12bit in ewp2} {viewer has aom but only show size file} {av1enc has libavif-00cbb77 and libgav1-142edec as no SIMD}
                  libWebP       1.1.0         c   [17 Dec 2020]
                  libPNG        1.6.38        c   [24 May 2020]
                  libTIFF       4.1.0         c   [12 Dec 2020] {old cameras with RichTIFFIPTC don't metadata}
                  libJPEG-turbo 2.0.91  8bit  c   [07 Dec 2020]
                  giflib        5.2.1         c   [24 Jun 2019]
                    zlib        1.2.11.1      c   [17 Sep 2020]

Coding testing images PNG and everything is known about this topic.
heifenc.exe image_21447_24bit.png -v -L -q 100 --no-alpha -p preset=placebo -p chroma=444 --matrix_coefficients=0 --full_range_flag=1 --enable-two-colr-boxes -o image_21447_24bit.heif
heifenc.exe image_21447_32bit.png -v -L -q 100 -p preset=placebo -p chroma=444 --matrix_coefficients=0 --full_range_flag=1 -o image_21447_32bit.heif
heifenc.exe image_21447_48bit.png -v -L -q 100 -b 12 --no-alpha -p preset=placebo --matrix_coefficients=0 -p chroma=444 --full_range_flag=1 -o image_21447_36bit.heif
heifenc.exe image_21447_24bit.png -v -L -q 100 --avif --no-alpha -p chroma=444 --matrix_coefficients=0 --full_range_flag=1 --enable-two-colr-boxes -o image_21447_24bit.avif {default effort 5} {error big file for 8bit}
heifenc.exe image_21447_32bit.png -v -L -q 100 --avif -p chroma=444 --matrix_coefficients=0 --full_range_flag=1 --enable-two-colr-boxes -o image_21447_32bit.avif {default effort 5} {error big file for 8bit}
heifenc.exe image_21447_48bit.png -v -L -q 100 --avif -b 12 --no-alpha -p chroma=444 --matrix_coefficients=0 --full_range_flag=1 --enable-two-colr-boxes -o image_21447_36bit.avif {default effort 5}
av1enc.exe -avif -q 100 -444 -size 1563x1558 -effort 5 -thread 4 image_21447_24bit.png -d image_21447_24bitw.avif
av1enc.exe -avif -q 100 -alpha_q 100 -444 -size 1563x1558 -effort 5 -thread 4 image_21447_32bit.png -d image_21447_32bitw.avif {error - no alpha}
av1enc.exe -avif -q 100 -444 -size 1563x1558 -effort 5 -thread 4 image_21447_48bit.png -d image_21447_48bitw.avif
cjxl.exe image_21447_24bit.png image_21447_24bit.jxl -v -q 100 -s 5 -C 1 --num_threads=4
cjxl.exe image_21447_32bit.png image_21447_32bit.jxl -v -q 100 -s 5 -C 1 --num_threads=4
cjxl.exe image_21447_48bit.png image_21447_48bit.jxl -v -q 100 -s 5 -C 1 --num_threads=4
cwp2.exe image_21447_24bit.png -summary -q 100 -nometadata -mt -effort 5 -uv_mode 2 -csp 0 -o image_21448_24bit.wp2
cwp2.exe image_21447_32bit.png -summary -q 100 -alpha_q 100 -nometadata -mt -effort 5 -uv_mode 2 -csp 0 -o image_21448_32bit.wp2
ewp2.exe image_21447_48bit.png -v -depth 12 -q 100 -nometadata -effort 5 -444 -csp 0 -o image_21448_48bit.wp2 {Error! Output format mixup.}
copen_j2k.exe -i image_21447_24bit.yuv -o image_21447_24bit.j2k -F 1563,1558,3,8,u@1x1:1x1:1x1 -mct 0 -b 64,64 -c [128,128],[256,256] -p CPRL -r 1 {Error: don't convert RGB to YCoCg(mct)}
cht_j2c.exe -i image_21447_24bit.yuv -o image_21447_24bit.j2c -dims {1563,1558} -num_comps 3 -signed false -bit_depth 8 -downsamp {1,1},{1,1},{1,1} -colour_trans false -block_size {64,64} -precincts {128,128},{256,256} -prog_order CPRL -reversible true {jph hasn't cannal alpha and rgb, images with heif/avif are bt709/bt601, range limited!!!} {Error: don't convert RGB to YCoCg(colour_trans)}
EncoderApp.exe --SummaryVerboseness --InputFile=image_21447_24bit.yuv --BitstreamFile=image_21447_24bit.266 --SourceWidth=1563 --SourceHeight=1558 --FrameRate=25.000 --InputBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 --MatrixCoefficients=0 --InputColorPrimaries=-1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=1 --HashME=1 --IBC=1 --DecodingRefreshType=1 --Profile=auto --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --CostMode=lossless --InputChromaFormat=444 --ChromaFormatIDC=444 --QP=0 --BDPCM=1 --ColorTransform=1 --VideoFullRange=1 --ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=0 --LFNST=0 --JointCbCr=0 --LoopFilterDisable=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --InternalBitDepth=0 --IntraPeriod=1 --GOPSize=1 --SearchRange=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=1 --GciPresentFlag=1 --Level=15.5 --Tier=high --RateControl=0 --SubpicDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --SbTMVP=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1 --VerCollocatedChroma=1 --EnableDecodingCapabilityInformation=1 --EnableOperatingPointInformation=1 --DefaultPtlDpbHrdMaxTidFlag=1 {no thread}

Test decoder
heifdec_08bit.exe image_21447_24bit.avif image_21447_24bita.png
heifdec_08bit.exe image_21447_32bit.avif image_21447_32bita.png
heifdec_16bit.exe image_21447_36bit.avif image_21447_48bita.png {Error: don't convert to PNG 48bit}
av1enc.exe -libgav1 -thread 4 image_21447_24bitw.avif -d image_21447_24bitwa.png {Error opening file: image_21447_24bitw.avif}
av1enc.exe -libgav1 -thread 4 image_21447_32bitw.avif -d image_21447_32bitwa.png {Error opening file: image_21447_24bitw.avif}
av1enc.exe -libgav1 -thread 4 image_21447_36bitw.avif -d image_21447_48bitwa.png {Error opening file: image_21447_24bitw.avif}
djxl.exe image_21447_24bit.jxl image_21447_24bitj.png --num_threads=4
djxl.exe image_21447_32bit.jxl image_21447_32bitj.png --num_threads=4
djxl.exe image_21447_48bit.jxl image_21447_48bitj.png --num_threads=4
dwp2.exe image_21448_24bit.wp2 -o image_21447_24bitw.png -v -mt -png
dwp2.exe image_21448_32bit.wp2 -o image_21447_32bitw.png -v -mt -png
dwp2.exe image_21448_48bit.wp2 -o image_21447_48bitw.png -v -mt -png
DecoderApp.exe -b image_21447_24bit.266 -o image_21447_24bitv.yuv
https://www.sendspace.com/file/88jr3r
Test convert metadata:
cjxl.exe image_21447_24bit_metadata.jpg image_21447_24bit.jxl -v -q 100 -s 5 -C 1 --num_threads=4 {error: don't convert exif}
cwp2.exe image_21447_24bit_metadata.jpg -summary -q 100 -mt -effort 5 -uv_mode 2 -csp 0 -o image_21448_24bit.wp2 {no ICCP, copy EXIF, no XMP}
cwp2.exe image_21447_24bit_metadata.tiff -summary -q 100 -mt -effort 5 -uv_mode 2 -csp 0 -o image_21448_24bit.wp2 {copy ICCP, error: don't copy EXIF, copy XMP}

[wandering_wizard]

Do you still have a the JxrEncApp.exe for Jpeg XR?

I want to test it but I can't compile it.

Thank You.

[Jamaika]

https://www.sendspace.com/file/5px7e9

[Jamaika]

The eXtra-fast Essential Video Encoder (XEVE) is an opensource and fast MPEG-5 EVC encoder.

MPEG-5 Essential Video Coding (EVC) is a future video compression standard of ISO/IEC Moving Picture Experts Grop (MPEG). The main goal of the EVC is to provide a significantly improved compression capability over existing video coding standards with timely publication of terms. The EVC defines two profiles, including "Baseline Profile" and "Main Profile". The "Baseline profile" contains only technologies that are older than 20 years or otherwise freely available for use in the standard. In addition, the "Main profile" adds a small number of additional tools, each of which can be either cleanly disabled or switched to the corresponding baseline tool on an individual basis.

https://github.com/mpeg5/xeve

https://www.sendspace.com/file/2suy0y

[Jamaika]

Merry Christmas

I add fixed working codec. There are still shortcomings, but this is new and we will not be brutal.
https://github.com/mpeg5/xeve/commit...58256bd3e07cea
https://www.sendspace.com/file/9jiuhc

xeve_app.exe -i "input.yuv" -o "output.evc" -v 2 -q 0 -d 8 -w 1280 -h 720 -z 30 -f 200 --profile 1 --level 6.2 --amvr 1

I haven't compiled the codec. I believe he has too many bugs.
https://github.com/fraunhoferhhi/vve...07cf6958fdfb03
https://github.com/fraunhoferhhi/vvd...5564296b12ab25

[Scope]

JPEG XL v0.2 - format freeze release
https://gitlab.com/wg1/jpeg-xl/-/releases/v0.2

JPEG XL is in the final stages of standardization and its codestream format is now frozen.
This release includes an encoder (cjxl) and decoder (djxl) that work together as well as a benchmark tool for comparison with other codecs (benchmak_xl). JPEG XL files encoded with previous versions of the software are not supported, but files encoded with version 0.2 will be supported by newer versions.
A decoder and encoder API in C is also present in this release, check the examples/ directory for its example usage. The C API is still a work in progress and likely to change both in API and ABI in future releases.

Jpeg XL 0.2 [31c71b0f] [Windows][Clang 11.0.0][64 bit]

[Jamaika]

Happy New Year 2021

https://www.sendspace.com/filegroup/...VwIRGIGVYRX5Aw

[Jamaika]

New codecs 10/01/2021

J P E G   \/ |
          /\ |_   e n c o d e r    [0.2.0-31c71b0f Supported/generated: Scalar]
Library:          brotli        1.0.9         c   [08 Jan 2021] {addition google}
                  brunsli       JXL           c++ [17 Dec 2020] {addition google}
                  butteraugli   JXL           c++ [01 Dec 2020] {addition google}
                  highway       0.7.0         c++ [08 Jan 2021] {addition google}
                  skcms                       c++ [07 Feb 2020] {addition google}
                  libsJPEG      0.1.0         c++ [19 Dec 2020] {addition google}
                  libJPEG-turbo 2.0.91  8bit  c   [04 Jan 2021]
                  lodePNG                     c++ [17 Oct 2020]
                   libPNG       1.6.38        c   [24 May 2020] {for APNG}
                   giflib       5.2.1         c   [24 Jun 2019]
                     zlib       1.2.11.1      c   [17 Sep 2020]
                  openexr       2.5.99        c++ [02 Dec 2020] {instead TIFF, Adobe DNG}
                    Imath       3.0.0         c++ [30 Dec 2020] {addition openexr}
Compiled by Jamaika

VVCSoftware: VTM Encoder Version 11.0-69eb16cb [Windows][GCC 10.2.1][64 bit] [SIMD=NONE]
VVCSoftware: HDRTools Version 0.20-0db34fbc

Library:          libheif/avif  1.11.0-9c7809a  8<>12b c++ [07 Jan 2021]
                     x265       3.4+35 8<>12b c++ [11 Dec 2020]
                  libde265      1.0.8  8<>12b c++ [02 Nov 2020]
                     aom        2.0.1         c   [10 Jan 2021]
                  libda1vd      0.8.1         c   [07 Jan 2021]
                  libJPEG-turbo 2.0.91  8bit  c   [04 Jan 2021]
                  libPNG        1.6.38        c   [24 May 2020]
                    zlib        1.2.11.1      c   [17 Sep 2020]

Library:          libWebP2      0.0.1-413df7c  8<>12b c++ [07 Jan 2021] {10<>12bit in ewp2}
                  libWebP       1.1.0          c   [08 Jan 2021]
                  libPNG        1.6.38         c   [24 May 2020]
                  libTIFF       4.1.0          c   [05 Jan 2021] {old cameras with RichTIFFIPTC don't metadata}
                  libJPEG-turbo 2.0.91    8bit c   [04 Jan 2021]
                  giflib        5.2.1          c   [24 Jun 2019]
                    zlib        1.2.11.1       c   [17 Sep 2020]
...............................................................
                     aom        2.0.1          c   [10 Jan 2021]
                  libavif       0.8.4.1        c   [05 Jan 2021]
                  libgav1       0.16.1 8_10bit c++ [21 Dec 2020]

Problem with import yuv/yuva and decode openjpeg2000/HT. Color transform{mct} is deprecated because it alters the color matrix.
Is the alpha channel importable? It is possible but it causes a large volume of openjpeg2000 files and nothing plays rgba. Generally not recommended and seems like an unfinished library dla HT Jpeg 2000

copen_j2k.exe -i image_rgba.yuv -o image_rgba.j2k -F 1563,1558,4,8,u@1x1:1x1:1x1:1x1 -mct 0 -b 64,64 -c [128,128],[256,256] -p CPRL -r 1
cht_j2c.exe -i image_rgba.yuv -o image_rgba.j2c -dims {1563,1558} -num_comps 4 -signed false -bit_depth 8 -downsamp {1,1},{1,1},{1,1},{1,1} -colour_trans false -block_size {64,64} -precincts {128,128},{256,256} -prog_order CPRL -reversible true

 -colour_trans (true) if there are three color components that are
               downsampled by the same amount then the color transform
               is optional. This option is also available if there are
               more than three colour components, where it is applied
               to the first three colour components

ojph error 0x01000031 at ojph_compress.cpp:684: we currently do not support color transform on yuv files. In any case, this not a normal usage scenario. The OpenJPH library however does support that, but ojph_compress.cpp must be modified to send all lines from one component before moving to the next component; this requires buffering components outside of the OpenJPH library
https://www.sendspace.com/file/7tfez2

[Marsu42]

"Good news, everyone": sooner or later, avif will be fixed for a less awkward rgb-lossless mode, with reasonable file size - it's using YCgCo-R instead of the current YCbCr hack, look at unlord's post here ... from the co-chair of the AOM Images Subgroup responsible for the AVIF format.

[Jamaika]

Testing gcc 2021.01.10 v11.0.0 with codecs image.

GCC 11 is very sensitive to the aom codecs. I don't know. Is gcc missing function definition in config? Are there any gaps in AOM codec? The functions in the AOM config are undefined in the codec, gaps and constant modifications.
I couldn't turn CONFIG_AV1_TEMPORAL_DENOISING off.

compound_type.c: In function 'av1_compound_type_rd':
compound_type.c:1360:9: warning: 'av1_build_inter_predictors_for_planes_single_buf' accessing 24 bytes in a region of size 8 [-Wstringop-overflow=]
 1360 |         av1_build_inter_predictors_for_planes_single_buf(xd, bsize, 0, 0, 0,
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1361 |                                                          preds0, strides);
      |                                                          ~~~~~~~~~~~~~~~~
compound_type.c:1360:9: note: referencing argument 6 of type 'uint8_t **' {aka 'unsigned char **'}
compound_type.c:1360:9: warning: 'av1_build_inter_predictors_for_planes_single_buf' accessing 12 bytes in a region of size 4 [-Wstringop-overflow=]
compound_type.c:1360:9: note: referencing argument 7 of type 'int *'
In file included from compound_type.c:18:
c:\msys1100\x86_64-w64-mingw32\include\av1\encoder\reconinter_enc.h:57:6: note: in a call to function 'av1_build_inter_predictors_for_planes_single_buf'
   57 | void av1_build_inter_predictors_for_planes_single_buf(
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

compound_type.c:1384:13: note: referencing argument 5 of type 'uint8_t **' {aka 'unsigned char **'}
compound_type.c:1384:13: warning: 'av1_build_wedge_inter_predictor_from_buf' accessing 12 bytes in a region of size 4 [-Wstringop-overflow=]

compound_type.c:1384:13: note: referencing argument 8 of type 'int *'
In file included from compound_type.c:18:
c:\msys1100\x86_64-w64-mingw32\include\av1\encoder\reconinter_enc.h:61:6: note: in a call to function 'av1_build_wedge_inter_predictor_from_buf'
   61 | void av1_build_wedge_inter_predictor_from_buf(MACROBLOCKD *xd, BLOCK_SIZE bsize,
      |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

firstpass.c:274:3: warning: 'av1_make_default_fullpel_ms_params' reading 31760 bytes from a region of size 22232 [-Wstringop-overread]
  274 |   av1_make_default_fullpel_ms_params(&ms_params, cpi, x, bsize, ref_mv,
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  275 |                                      first_pass_search_sites,
      |                                      ~~~~~~~~~~~~~~~~~~~~~~~~
  276 |                                      fine_search_interval);
      |                                      ~~~~~~~~~~~~~~~~~~~~~

Problem with thread, mutex, invoke, future functions and modification of these functions under C++21. I had to add some older functions to gcc for the compiler to work.

color_management.cc:884:9: warning: 'void* memset(void*, int, size_t)' writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
  884 |   memset(icc_sum.data() + 64, 0, 4);
      |   ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~

Creates codecs much slower than 10.2.0. Codecs are 1.5 times larger in size with the same settings.
Dislikes undefined but predefined functions.

ojph_params.cpp: In member function 'bool ojph::local::param_sot::read(ojph::infile_base*, bool)':
ojph_params.cpp:1128:47: warning: writing 2 bytes into a region of size 1 [-Wstringop-overflow=]
 1128 |           Lsot = 0; Isot = 0; Psot = 0; TPsot = 0; TNsot = 0;
      |                                         ~~~~~~^~~
In file included from ojph_params.cpp:45:
ojph_params_local.h:581:11: note: destination object 'ojph::local::param_sot::TPsot' of size 1
  581 |       ui8 TPsot;
      |           ^~~~~

ui16 Lsot = 0; ui16 Isot = 0; ui32 Psot = 0; ui8 TPsot = 0; ui8 TNsot = 0;