Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th December 2020, 22:23   #361  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
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.
Jamaika is offline   Reply With Quote
Old 15th December 2020, 11:24   #362  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,563
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.
foxyshadis is offline   Reply With Quote
Old 15th December 2020, 13:42   #363  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 80
Quote:
Originally Posted by foxyshadis View Post
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.

Quote:
Originally Posted by foxyshadis View Post
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.
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 15th December 2020 at 13:48.
Marsu42 is offline   Reply With Quote
Old 18th December 2020, 09:24   #364  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
New codecs 18/12/2020

Code:
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
Code:
VVCSoftware: VTM Encoder Version 11.0-9d3f3afa [Windows][GCC 10.2.1][64 bit] [SIMD=NONE]
VVCSoftware: HDRTools Version 0.20-0db34fbc
Code:
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
Code:
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}

Last edited by Jamaika; 14th January 2021 at 09:04.
Jamaika is offline   Reply With Quote
Old 19th December 2020, 14:19   #365  |  Link
wandering_wizard
Registered User
 
Join Date: Dec 2020
Posts: 1
JxrEncApp.exe

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

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

Thank You.
wandering_wizard is offline   Reply With Quote
Old 19th December 2020, 17:36   #366  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
https://www.sendspace.com/file/5px7e9
Jamaika is offline   Reply With Quote
Old 20th December 2020, 00:06   #367  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
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 is offline   Reply With Quote
Old 24th December 2020, 15:11   #368  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
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

Last edited by Jamaika; 28th December 2020 at 08:34.
Jamaika is offline   Reply With Quote
Old 24th December 2020, 21:50   #369  |  Link
Scope
Registered User
 
Join Date: Feb 2020
Posts: 16
JPEG XL v0.2 - format freeze release
https://gitlab.com/wg1/jpeg-xl/-/releases/v0.2
Quote:
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]
Scope is offline   Reply With Quote
Old 31st December 2020, 15:36   #370  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
Happy New Year 2021

https://www.sendspace.com/filegroup/...VwIRGIGVYRX5Aw
Jamaika is offline   Reply With Quote
Old 10th January 2021, 17:50   #371  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
New codecs 10/01/2021

Code:
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
Code:
VVCSoftware: VTM Encoder Version 11.0-69eb16cb [Windows][GCC 10.2.1][64 bit] [SIMD=NONE]
VVCSoftware: HDRTools Version 0.20-0db34fbc
Code:
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]
Code:
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

Code:
 -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

Last edited by Jamaika; 11th January 2021 at 08:09.
Jamaika is offline   Reply With Quote
Old 11th January 2021, 23:15   #372  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 80
"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.
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 11th January 2021 at 23:22.
Marsu42 is offline   Reply With Quote
Old 16th January 2021, 11:19   #373  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
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.
Code:
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.
Code:
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.
Code:
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;

Last edited by Jamaika; 16th January 2021 at 11:46.
Jamaika is offline   Reply With Quote
Old 21st January 2021, 10:24   #374  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
Testing gcc 2021.01.17 v11.0.0 with webp2.
Code:
In member function 'void WP2::Quantizer::QuantizeImpl(const uint32_t*, const uint16_t*, size_t, uint32_t, uint32_t, int, size_t, float)',
    inlined from 'void WP2::Quantizer::Quantize(const uint32_t*, const uint16_t*, size_t, uint32_t, uint32_t, int, WP2::Quantizer::Config**)' at quantizer.cc:72:15:
quantizer.cc:113:31: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
  113 |       bits[n_max_freq_bits++] = max_freq_bits;
      |       ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
In file included from quantizer.cc:21:
c:\msys1100\x86_64-w64-mingw32\include\src\utils\quantizer.h: In member function 'void WP2::Quantizer::Quantize(const uint32_t*, const uint16_t*, size_t, uint32_t, uint32_t, int, WP2::Quantizer::Config**)':
c:\msys1100\x86_64-w64-mingw32\include\src\utils\quantizer.h:107:11: note: at offset 14 into destination object 'WP2::Quantizer::bits_' of size 14
  107 |   uint8_t bits_[kConfigNbr][kMaxFreqBits];
      |           ^~~~~
Jamaika is offline   Reply With Quote
Old 21st January 2021, 13:14   #375  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 126
yes, that's a bug that was supposed to be fixed in gcc 10.2.xx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955

Will try to work around it, it's annoying noise...
skal is offline   Reply With Quote
Old 21st January 2021, 22:11   #376  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 126
Quote:
Originally Posted by skal View Post
Will try to work around it, it's annoying noise...
Should be ok now at 2870b7588
skal is offline   Reply With Quote
Old 22nd January 2021, 08:11   #377  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
Thx, I put GCC 11.0.0 aside. Currently I can't compile the thread because I'm struggling with the new aom version.
Testing gcc 2021.01.17 v10.2.1 with codecs.
Bugs in codec AOM
#define CONFIG_LPF_MASK 1
Code:
loopfiltermask.c: In function 'av1_store_bitmask_vartx':
loopfiltermask.c:1263:11: error: 'MB_MODE_INFO' has no member named 'sb_type'
 1263 |       mbmi->sb_type, cm->seq_params.subsampling_x,
      |           ^~
loopfiltermask.c: In function 'av1_store_bitmask_other_info':
loopfiltermask.c:1427:29: error: 'MB_MODE_INFO' has no member named 'skip'; did you mean 'tx_skip'?
 1427 |   const int is_skip = mbmi->skip && is_inter_block(mbmi);
      |                             ^~~~
      |                             tx_skip
mbmi->bsize, cm->seq_params.subsampling_x,
const int is_skip = mbmi->skip_txfm && is_inter_block(mbmi);


Code:
decoder.c: In function 'dec_set_mb_mi':
decoder.c:73:30: warning: passing argument 1 of 'av1_alloc_loop_filter_mask' from incompatible pointer type [-Wincompatible-pointer-types]
   73 |   av1_alloc_loop_filter_mask(mi_params);
      |                              ^~~~~~~~~
      |                              |
      |                              CommonModeInfoParams *
In file included from decoder.c:28:
c:\msys1021\x86_64-w64-mingw32\include\av1\common\alloccommon.h:50:50: note: expected 'struct AV1Common *' but argument is of type 'CommonModeInfoParams *'
   50 | int av1_alloc_loop_filter_mask(struct AV1Common *cm);
      |                                ~~~~~~~~~~~~~~~~~~^~
av1_alloc_loop_filter_mask((struct AV1Common*) mi_params);

#define CONFIG_REALTIME_ONLY 1
Code:
firstpass.c: In function 'av1_first_pass':
firstpass.c:1224:5: warning: implicit declaration of function 'av1_fp_encode_tiles_row_mt'; did you mean 'av1_encode_tiles_row_mt'? [-Wimplicit-function-declaration]
 1224 |     av1_fp_encode_tiles_row_mt(cpi);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |     av1_encode_tiles_row_mt
Code:
tpl_model.c: In function 'av1_tpl_setup_stats':
tpl_model.c:1438:31: error: 'av1_tpl_row_mt_sync_read_dummy' undeclared (first use in this function); did you mean 'av1_row_mt_sync_read_dummy'?
 1438 |   tpl_row_mt->sync_read_ptr = av1_tpl_row_mt_sync_read_dummy;
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                               av1_row_mt_sync_read_dummy
Code:
pass2_strategy.c: In function 'get_projected_gfu_boost':
pass2_strategy.c:634:23: warning: implicit declaration of function 'av1_get_gfu_boost_projection_factor' [-Wimplicit-function-declaration]
  634 |   double tpl_factor = av1_get_gfu_boost_projection_factor(
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pass2_strategy.c: In function 'get_projected_kf_boost':
pass2_strategy.c:2785:23: warning: implicit declaration of function 'av1_get_kf_boost_projection_factor' [-Wimplicit-function-declaration]
 2785 |   double tpl_factor = av1_get_kf_boost_projection_factor(cpi->rc.frames_to_key);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define CONFIG_REALTIME_ONLY 0
Does CONFIG_REALTIME_ONLY have to always be on?
Code:
restoration.c: In function 'sgrproj_filter_stripe':
restoration.c:962:5: warning: implicit declaration of function 'av1_apply_selfguided_restoration'; did you mean 'av1_apply_selfguided_restoration_c'? [-Wimplicit-function-declaration]
  962 |     av1_apply_selfguided_restoration(
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |     av1_apply_selfguided_restoration_c
Code:
warped_motion.c: In function 'warp_plane':
warped_motion.c:736:3: warning: implicit declaration of function 'av1_warp_affine'; did you mean 'av1_warp_affine_c'? [-Wimplicit-function-declaration]
  736 |   av1_warp_affine(mat, ref, width, height, stride, pred, p_col, p_row, p_width,
      |   ^~~~~~~~~~~~~~~
      |   av1_warp_affine_c
Code:
warped_motion.c: In function 'segmented_frame_error':
warped_motion.c:774:20: warning: implicit declaration of function 'av1_calc_frame_error'; did you mean 'av1_calc_frame_error_c'? [-Wimplicit-function-declaration]
  774 |       sum_error += av1_calc_frame_error(ref + j + i * stride, stride,
      |                    ^~~~~~~~~~~~~~~~~~~~
      |                    av1_calc_frame_error_c
Change:
static AOM_INLINE void init_simple_motion_search_mvs(

Last edited by Jamaika; 22nd January 2021 at 09:34.
Jamaika is offline   Reply With Quote
Old 23rd January 2021, 14:13   #378  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
Testing gcc 2021.01.17 v11.0.0 with codecs 23.01.2021

Description of the AOM functions with which there are sometimes problems:
#define CONFIG_LPF_MASK 1
#define CONFIG_AV1_TEMPORAL_DENOISING 0
#define CONFIG_REALTIME_ONLY 0 ??? // This definition means nothing. It is undergoing reorganization. Some features are turned on even though they are turned off and only the creators know that. File "av1_rtcd.h" shouldn't be defined as "av1_rtcd_defs.pl" recommends.

Added codec files with SIMD functions: NONE/SSE4.1_4.2

Problems during compilation.
To compile the std :: thread, std :: mutex or std :: future functions in GCC 11.0, you must lose the older thread, mutex, future functions from the 11/11/2020 version. I tried to correct it, but I didn't know that much about it.
https://github.com/meganz/mingw-std-threads/pull/74
One codec, but each addition has different SIMD versions and is not compatible with the __SSEX__ or __AVXX__ codec functions. Functions must be added manually.
In the AOM codec, adding the SIMD function as HAVE_SSE2 is not enough in GCC. Must be configured config with __SSEX__ or __AVXX__ functions. Otherwise we have no SIMD. I don't know if assembler in encoder is required.

Problem with google highway SIMD SSE41.
Code:
In file included from c:\msys1100\x86_64-w64-mingw32\include\hwy\highway.h:257,
                 from c:\msys1100\x86_64-w64-mingw32\include\lib\jxl\extras\codec_png.h:24,
                 from codec_png.cc:15:
c:\msys1100\x86_64-w64-mingw32\include\hwy\ops\x86_128-inl.h: In function 'size_t hwy::N_SSE4::StoreMaskBits(hwy::N_SSE4::Mask128<T, N>, uint8_t*)':
c:\msys1100\x86_64-w64-mingw32\include\hwy\ops\x86_128-inl.h:2583:3: error: there are no arguments to 'memcpy' that depend on a template parameter, so a declaration of 'memcpy' must be available [-fpermissive]
 2583 |   memcpy(p, &bits, kNumBytes);
      |   ^~~~~~
c:\msys1100\x86_64-w64-mingw32\include\hwy\ops\x86_128-inl.h:2583:3: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
In file included from c:\msys1100\x86_64-w64-mingw32\include\hwy\highway.h:257,
                 from c:\msys1100\x86_64-w64-mingw32\include\lib\jxl\extras\codec_pnm.h:24,
                 from codec_pnm.cc:15:
c:\msys1100\x86_64-w64-mingw32\include\hwy\ops\x86_128-inl.h: In function 'size_t hwy::N_SSE4::StoreMaskBits(hwy::N_SSE4::Mask128<T, N>, uint8_t*)':
c:\msys1100\x86_64-w64-mingw32\include\hwy\ops\x86_128-inl.h:2583:3: error: there are no arguments to 'memcpy' that depend on a template parameter, so a declaration of 'memcpy' must be available [-fpermissive]
 2583 |   memcpy(p, &bits, kNumBytes);
      |   ^~~~~~
c:\msys1100\x86_64-w64-mingw32\include\hwy\ops\x86_128-inl.h:2583:3: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
Problem vvenc v2.1.0
We cannot reproduce the problem. Also, we are working on cleaning up the lib interface, so maybe the problems will be resolved within this refactoring.
https://github.com/fraunhoferhhi/vvenc/pull/17

Available SIMD functions in GCC 11.0.0 codecs added by me
libWebP2 SSE42 // why is only SSE42?
libWebP SSE41
openEXR SSE41
jpegXL SSE41
libgav1 SSE41
jvetvcc SSE41

Error decoding verbose libwebp2
dwp2.exe image_21448_24bit.wp2 -o image_21447_24bitw.png -v -mt -png
Assertion failed: cost == nullptr, file symbols_dec.cc, line 311

https://www.sendspace.com/file/1u88rw
Added untested codecs GCC 10.2.1 with SIMD Scalar(None)/SSE41/SSE42/AVX/AVX2/AVX3
Jamaika's doubts:
What is the value in libjpeg AVX3 for ALIGN_SIZE?
Code:
#define ALIGN_SIZE  32 /* Most of the SIMD instructions we support require
                          16-byte (128-bit) alignment, but AVX2 requires
                          32-byte alignment. */
What does avx3 mean and does avx3 tolerate all avx512 in gcc?
https://www.sendspace.com/file/tckh9u

Last edited by Jamaika; 24th January 2021 at 22:21.
Jamaika is offline   Reply With Quote
Old 27th January 2021, 10:18   #379  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 791
vvenc and vvdec not under ffmpeg. Libraries in C++14 .

Opensource for maniac
https://www.sendspace.com/file/wvmv5p

Last edited by Jamaika; 27th January 2021 at 10:23.
Jamaika is offline   Reply With Quote
Old 27th January 2021, 22:17   #380  |  Link
skal
Registered User
 
Join Date: Jun 2003
Posts: 126
Quote:
Originally Posted by Jamaika View Post
Error decoding verbose libwebp2
dwp2.exe image_21448_24bit.wp2 -o image_21447_24bitw.png -v -mt -png
Assertion failed: cost == nullptr, file symbols_dec.cc, line 311
Thanks for the report! it'll be fixed in the next sync...
skal is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.