Crazy family JPEG formats (2017).

[paul97]

Jamaika, is it that commit ?
https://chromium.googlesource.com/co...f0aee3fbe02e84
Friday November 20th

[Jamaika]

Yes the same
https://www.sendspace.com/file/3glokx

[Jamaika]

New codecs, untestet with bugs fixed 25.11.2020
https://www.sendspace.com/file/dbx3jx

[Jamaika]

New codecs 27/11/2020

J P E G   \/ |
          /\ |_   e n c o d e r    [0.1.0-05a84bb5 Supported/generated: Scalar]
Library:          brotli        1.0.9         c   [24 Sep 2020] {addition google}
                  brunsli                     c++ [11 Aug 2020] {addition google}
                  butteraugli   JXL           c++ [06 Nov 2020] {addition google}
                  highway       0.1           c++ [26 Nov 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   [25 Nov 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++ [23 Nov 2020] {instead TIFF, Adobe DNG}
                    Imath       3.0.0         c++ [26 Oct 2020] {addition openexr}
Compiled by Jamaika

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

Library:          libheif/avif  1.9.1 8+10+12 c++ [24 Nov 2020]
                  x265          3.5+1 8+10+12 c++ [27 Oct 2020]
                  libde265      1.0.8 8+16bit c++ [02 Nov 2020]
                  libaom        2.0.0         c   [27 Nov 2020]
                  libda1vd      0.8.0         c   [23 Nov 2020]
                  libJPEG-turbo 2.0.91  8bit  c   [25 Nov 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         c++ [24 Nov 2020]
                  libWebP       1.6.38        c   [23 Nov 2020]
                  libPNG        1.1.0         c   [24 May 2020]
                  libTIFF       4.1.0         c   [21 Nov 2020]
                  libJPEG-turbo 2.0.91  8bit  c   [25 Nov 2020]
                  giflib        5.2.1         c   [24 Jun 2019]
                    zlib        1.2.11.1      c   [17 Sep 2020]

https://www.sendspace.com/file/sno633

Beginner's Tips:
Certain definitions need to be changed for MINGW. This applies to older libraries such as DNG SDK, freeglut.
For example:

defined(_MSC_VER) && _MSC_VER >= 1900

let's change to

(defined(_MSC_VER) && _MSC_VER >= 1900) || defined(__MINGW32__) || defined(__MINGW64__)
(defined(_MSC_VER) && _MSC_VER < 1900) || !defined(__MINGW32__) || !defined(__MINGW64__)

What to choose for Windows 64bit?

#if defined(HAVE_STDINT_H)
#   include <stdint.h>
    typedef uint64_t fg_time_t;
#elif defined(HAVE_INTTYPES_H)
#   include <inttypes.h>
    typedef uint64_t fg_time_t;
#elif defined(HAVE_U__INT64)
    typedef unsigned __int64 fg_time_t;
#elif defined(HAVE_ULONG_LONG)
    typedef unsigned long long fg_time_t;
#else
    typedef unsigned long fg_time_t;
#endif

#  ifdef _WIN64
#     ifdef __GNUC__
         typedef unsigned long long fg_time_t;
#     elif defined(_MSC_VER) && _MSC_VER >= 1900
#        include <inttypes.h>
         typedef uint64_t fg_time_t;
#     else
         typedef unsigned __int64 fg_time_t;
#     endif
#  else
      typedef unsigned long fg_time_t;
#  endif

Unfortunately selecting HAVE_ULONG_LONG causes the software to run slower.

Strange x265 no upgrades.
I failed to properly configure the decoder under aom. I can't believe he's not dating MINGW. If someone succeeds, let him praise him.

[LigH]

Originally Posted by Jamaika

Beginner's Tips:
Certain definitions need to be changed for MINGW. This applies to older libraries such as DNG SDK, freeglut.

Are these general optimization tips which could potentially apply to several codec projects? If so, they might be interesting to the media-autobuild team as well. But I'm not sure how and where to suggest them...

[Jamaika]

Originally Posted by LigH

Are these general optimization tips which could potentially apply to several codec projects? If so, they might be interesting to the media-autobuild team as well. But I'm not sure how and where to suggest them...

I reported fix in libheif.
https://github.com/strukturag/libheif/pull/320
I created a revised dng sdk version for libraw and gopro for my own purposes.
https://github.com/Jamaika1/dng_sdk_..._gpr_sdk_1.0.0
However, I've already heard that outdated designs should not be improved. They don't use the latest jpeg2000ht, jpegxl or jpegxs codecs. I hope Adobe doesn't take offense, or worse.

[Marsu42]

Originally Posted by Jamaika

I reported fix in libheif.

Thanks again for your great work and releasing the binaries regularly!

I wonder which will come out on top, libheif or libavif - the latter has some work done for lossless encoding, but libheif probably is more flexible and migh even easily adopt x266 or another oss vvc encoder once its available.

Pity these video compression spin-offs are not really designed for intra-compression, as developing image-only codecs doesn't seem to be commercially feasible... thus leaving us with jpeg-xl which is really late in the game competing with heif and avif.
.

Originally Posted by Jamaika

Strange x265 no upgrades.

Afaik the main dev of x265 left the project some time ago for a competing commercial encoder - you can track this when development slowed or nearly came to a stop.

[Jamaika]

help comparison of photo codecs

[Jamaika]

Originally Posted by Marsu42

I wonder which will come out on top, libheif or libavif - the latter has some work done for lossless encoding, but libheif probably is more flexible and migh even easily adopt x266 or another oss vvc encoder once its available.

Indeed, there have been such suggestions that libheif might support vvc, x266. Apparently this can be done by mp4 with gpac. Unfortunately nothing is said at the moment about the new mp5 container, why not libheif. However, I say that it will not come out because for this you need willingness and money.
As an amateur, I combined libbpg with vvc as an inefficient codec. This codec should be with thread functions. The library fraunhoferhhi vvc is currently suspended.

[Thundik81]

Originally Posted by Jamaika

help comparison of photo codecs
[3.82 Mo]

Use pingo!

[foxyshadis]

Originally Posted by Marsu42

I wonder which will come out on top, libheif or libavif - the latter has some work done for lossless encoding, but libheif probably is more flexible and migh even easily adopt x266 or another oss vvc encoder once its available.

Pity these video compression spin-offs are not really designed for intra-compression, as developing image-only codecs doesn't seem to be commercially feasible... thus leaving us with jpeg-xl which is really late in the game competing with heif and avif.

For a long time libavif had better colorspace support and worked better with aom, but at this point libheif has at least feature parity and some, plus a wide choice of encoders, and it's updated to fix bugs (in its code or to work around other implementations) much more quickly. The bleeding edge libheif works a lot better with both iPhone and Chrome than libavif. Downside, the API is very unstable.

The same thing that makes libheif so strong is what makes it so weak -- Dirk Farin has committed more resources to it the last couple of years than the more diffused internal work of AOM combined to theirs. But that also means it doesn't pass the bus test, and could easily die on the vine at any time.

I will say, though, that even if some of the new xx jpegs are slightly better at compacting data, x265 and aom/svt-av1 are no slouch either. I'm more than willing to give up 5% vs maximum possible compression to get an overall format that finally isn't limited by early 90's technology. Just the breathing room beyond 8-bit is such a breath of fresh air.

[Jamaika]

Originally Posted by foxyshadis

For a long time libavif had better colorspace support and worked better with aom, but at this point libheif has at least feature parity and some, plus a wide choice of encoders, and it's updated to fix bugs (in its code or to work around other implementations) much more quickly. The bleeding edge libheif works a lot better with both iPhone and Chrome than libavif. Downside, the API is very unstable.

The most interesting thing is that there are currently several dozen libavif containers.
https://github.com/AOMediaCodec/av1-avif
https://github.com/AOMediaCodec/libavif
https://github.com/strukturag/libheif
https://github.com/link-u/cavif
https://github.com/link-u/davif

[Jamaika]

New codecs 04/12/2020

J P E G   \/ |
          /\ |_   e n c o d e r    [0.1.0-739e6cd1 Supported/generated: Scalar]
Library:          brotli        1.0.9         c   [24 Sep 2020] {addition google}
                  brunsli                     c++ [11 Aug 2020] {addition google}
                  butteraugli   JXL           c++ [01 Dec 2020] {addition google}
                  highway       0.1           c++ [02 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   [28 Nov 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++ [26 Oct 2020] {addition openexr}
Compiled by Jamaika

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

Library:          libheif/avif  1.9.1 8+10+12 c++ [24 Nov 2020]
                  x265          3.5+1 8+10+12 c++ [27 Oct 2020]
                  libde265      1.0.8 8+16bit c++ [02 Nov 2020]
                  libaom        2.0.1         c   [04 Dec 2020]
                  libda1vd      0.8.0         c   [23 Nov 2020]
                  libJPEG-turbo 2.0.91  8bit  c   [28 Nov 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         c++ [03 Dec 2020]
                  libWebP       1.6.38        c   [23 Nov 2020]
                  libPNG        1.1.0         c   [24 May 2020]
                  libTIFF       4.1.0         c   [21 Nov 2020]
                  libJPEG-turbo 2.0.91  8bit  c   [28 Nov 2020]
                  giflib        5.2.1         c   [24 Jun 2019]
                    zlib        1.2.11.1      c   [17 Sep 2020]

https://www.sendspace.com/file/9fnmfp
opensource
https://www.sendspace.com/file/bikxal

File compatibility AV1 wifh WEBP2. When I added CONFIG_DEBUG it turned out that the photo converter webp2 doesn't support color subsampling 444. Error or not error. Libavif containers older than 0.8.4.1 don't have RGB format, so free players do not.

av1enc.exe -avif -q 100 -444 -size 1563x1558 -effort 5 -thread 4 -O image_21447.av1 -D image_21447.png
ERROR: Failed to encode: Decoding of color planes failed
Error while computing the distortion.

but it is possible for libheif. Unfortunately conversion speed 'effort' can't be set in libheif.
For lossless the size of photos is effort dependent. It seems to be the so-called nearby-lossless. The greater the precision of details, the greater the size of the photos.
heifenc_08bit_hdr.exe image_21447.y4m -v -q 100 --avif --no-alpha -p chroma=444 --matrix_coefficients=0 -o image_21447.avif

[Marsu42]

Originally Posted by foxyshadis

I will say, though, that even if some of the new xx jpegs are slightly better at compacting data, x265 and aom/svt-av1 are no slouch either. I'm more than willing to give up 5% vs maximum possible compression to get an overall format that finally isn't limited by early 90's technology. Just the breathing room beyond 8-bit is such a breath of fresh air.

I absolutely agree that newer codecs supporting hdr is essential esp. when handling sources that provide these bit depth - like downsized 4k or dslr images.

Alas, looking at lossless compression it's a lot more than 5% difference - probably not the main focus of these codecs, but my use case, so ymmv and feel free to ignore.

I'm encoding 8bit rgb with a public sample image https://github.com/link-u/avif-sampl...aster/hato.png

1. 8'405'354 hato.heic
2. 6'652'706 hato.png
3. 5'439'797 hato.avif
4. 4'526'038 hato.webp
5. 4'225'623 hato.wp2

The heic result with libheif is strange, maybe I'm doing something wrong?

heifenc -p chroma=444 --lossless --matrix_coefficients=0 -e x265 -p x265:psy-rd=0 -p x265:ctu=64)

The avif result (using libavif with libaom) is ok, but there's a significant 20%-ish difference to webp and (current) webp2.

Of course this isn't extensive testing, but it squares with my results so far trying a lot of codecs on my photography images. I'll try 10bit next when webp2 has added it.

[Jamaika]

Originally Posted by Marsu42

I
The heic result with libheif is strange, maybe I'm doing something wrong?

heifenc -p chroma=444 --lossless --matrix_coefficients=0 -e x265 -p x265:psy-rd=0 -p x265:ctu=64)

Use heifenc.exe -P first
Parameters for encoder `x265 HEVC encoder (3.5+1)`:
quality, default=50, [0;100]
lossless, default=false
preset, default=slow, { ultrafast,superfast,veryfast,faster,fast,medium,slow,slower,veryslow,placebo }
tune, default=ssim, { psnr,ssim,grain,fastdecode }
tu-intra-depth, default=2, [1;4]
complexity, [0;100]
chroma, default=420, { 420,422,444 }
These parameters don't have the x265 prefix and must be used separately. Prefixed with x265, these are the functions of the x265 codec.

heifenc -v -b 8 -L -e x265 -p preset=placebo -p chroma=444 -p x265:psy-rd=0 -p x265:ctu=64 input_image -o heif_image

Importing png files. If we have 8bit png, we have 8bit heif on the output. If we have 16bit png, we can only output 10 / 12bit heif. Unfortunately for matrix coefficients 0 {RGB} there is some bug. The files are too large.
Some codec modifications
https://www.sendspace.com/file/7w4wn0

[LigH]

Do you also know BPG (Better Portable Graphics)? It's another image format based on HEIF. It is so elaborate that even decompressing ~20 MPx images may take several seconds on a Ryzen.

Apart from separate tools, XnViewMP supports its decoding and basic encoding (tuning via plugin INI).

[Marsu42]

Originally Posted by Jamaika

Use heifenc.exe -P first

Thanks, with your options the filesize is a lot smaller now:

... placebo adds a small difference so it probably should be default, or at least mentioned in the help?

... not setting --matrix_coefficients=0 is what makes the big difference, BUT heicenc -h clearly states it should be included - so is the image with your options actually rgb-lossless like webp? If so, 'true' rgb heic seems to be as bad as 'true' rgb avif :-\

Note: to get lossless encoding, you need this set of options:
  -L                       switch encoder to lossless mode
  -p chroma=444            switch off color subsampling
  --matrix_coefficients=0  encode in RGB color-space

Originally Posted by LigH

Do you also know BPG

Yes, I know that one, I was very excited back then and personally bugged the XnView author to include it. I feel rather bad about that by now because like flif, bpg clearly isn't going anywere :-\

However, I've seen Jamaica added the vvc codec to it, so it's interesting for experimentation. For my personal use, I'm looking for a container/codec format that is lossless _and_ has high compression _and_ is widely supported (viewer, browser).

Btw I agree with the premise of JPEG-XL (as seen in some slided on youtube): current storage and bandwith capacities make lossless image compression much more relevant nowadays. So it's the use cases are either "as small as possible" for websites with a lot of images and traffic, or "lossless" for everything else.

[Jamaika]

Originally Posted by Marsu42

However, I've seen Jamaica added the vvc codec to it, so it's interesting for experimentation. For my personal use, I'm looking for a container/codec format that is lossless _and_ has high compression _and_ is widely supported (viewer, browser).

New versions of VVC 0.2.0.0 with multitreads have been added. They have some bugs, but for those who are willing, I can create them in my free time.

Compilation problems in GCC:
dav1d - I know it's superseded by newer libgav1, but it still exists
For users aom is more annoying that decoder has to be with assembler.

decode.c:2934:26: warning: assignment to 'pixel *' {aka 'short unsigned int *'} from incompatible pointer type 'uint8_t *' {aka 'unsigned char *'} [-Wincompatible-pointer-types]
 2934 |         f->ipred_edge[1] = ptr + ipred_edge_sz * 128 * 1;
      |                          ^

vvdec - v0.2.0.1

DecCu.cpp: In member function 'void DecCu::TaskDeriveDMVRMotionInfo(CodingStructure&, const UnitArea&)':
DecCu.cpp:172:92: error: call to non-'constexpr' function 'const _Tp& std::max(const _Tp&, const _Tp&) [with _Tp = int]'
  172 |       static constexpr unsigned scale = 4 * std::max<int>(1, 4 * AMVP_DECIMATION_FACTOR / 4);
      |                                                                                            ^
In file included from c:\msys1021\include\c++\10.2.1\algorithm:61,
                 from c:\msys1021\x86_64-w64-mingw32\include\commonlib\CommonDef.h:54,
                 from c:\msys1021\x86_64-w64-mingw32\include\commonlib\contexts.h:54,
                 from BinDecoder.h:54,
                 from CABACReader.h:54,
                 from DecCu.h:58,
                 from DecCu.cpp:51:
c:\msys1021\include\c++\10.2.1\bits\stl_algobase.h:254:5: note: 'const _Tp& std::max(const _Tp&, const _Tp&) [with _Tp = int]' declared here
  254 |     max(const _Tp& __a, const _Tp& __b)
      |     ^~~

vvenc - v0.2.0.0

CommonDef.h:600:55: warning: ignoring attributes on template argument 'void(int, const char*, va_list)' {aka 'void(int, const char*, char*)'} [-Wignored-attributes]
  600 | extern std::function<void( int, const char*, va_list )> g_msgFnc;
      |                                                       ^

https://www.sendspace.com/file/72eec5
opensource
https://www.sendspace.com/file/7eln73

[LigH]

I hope you can spare a little time to support MABS supporting the HHI VVC codecs, explaining your patches there.

[Jamaika]

New codecs 04/12/2020

J P E G   \/ |
          /\ |_   e n c o d e r    [0.1.0-739e6cd1 Supported/generated: Scalar]
Library:          brotli        1.0.9         c   [24 Sep 2020] {addition google}
                  brunsli                     c++ [11 Aug 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++ [05 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 8+10+12 c++ [24 Nov 2020] {don't work decoder aom}
                  x265          3.5+1 8+10+12 c++ [27 Oct 2020]
                  libde265      1.0.8 8+16bit c++ [02 Nov 2020]
                  libaom        2.0.1         c   [11 Dec 2020]
                  libda1vd      0.8.0         c   [23 Nov 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-4223db6  8bit  c++ [11 Dec 2020] {10<>12bit in ewp2} {viewer has aom but only show size file} {av1enc has libavif-5559185 and libgav1-142edec as no SIMD}
                  libWebP       1.6.38        c   [23 Nov 2020]
                  libPNG        1.1.0         c   [24 May 2020]
                  libTIFF       4.1.0         c   [21 Nov 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]

heifenc.exe image_21447{24/32bit}.y4m -v -L -q 100 --no-alpha -p preset=placebo -p chroma=444 --matrix_coefficients=0 {don't small YCoCg=lossless RGB} -o image_21447{24/32bit}.heif
heifenc.exe image_21447{48bit}.y4m -v -L -q 100 -b 12 --avif --no-alpha -p preset=9 -p chroma=444 -o image_21447{36bit}.avif
av1enc.exe -q 100 -444 -size 1563x1558 -effort 5 -thread 4 -O {only auto name file 24bit} -D image_21447{48bit}.png
av1enc.exe -avif -q 68 -420 -size 1563x1558 -effort 5 -thread 4 -O image_21447.avif {don't name avif} -D image_21447.png
av1enc.exe -libgav1 -q 100 -444 -size 1563x1558 -thread 4 -O image_21447.png -D image_21447.avif/av1 {don't read avif/av1} {don't decode image avif/aom}
cjxl.exe image_21447.ppm image_21447.jxl -v -q 68 -s 9 -C 1{YCoCg} --num_threads=4
cwp2.exe image_21447{8bit}.ppm -summary -q 68 -nometadata -mt -effort 5 -uv_mode 2 -csp 0{YCoCg} -o image_21448{8bit}.wp2
ewp2.exe image_21447{16bit}.png -v -depth 12 -q 68 -nometadata -effort 5 -csp 0{YCoCg} -444 -o image_21448{12bit}.wp2
VVEncoderApp.exe --preset medium --profile main10 --level 6.3 -s 1563x1558{only standard size video 16:9} -f 1 -c yuv420 -r 30 -t 4 -q 0 -o file.266
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

https://www.sendspace.com/file/mm09e6

Test viewer WEBP2
After many tests I came to the conclusion that the viewer works only for CONFIG_MAX_DECODE_PROFILE equal to 2. I don't know why it is because the default for google chronium is 0 and then it doesn't work.
Oddly enough, the viewer works very slowly for thread zero ie encoder/decoder aom, but av1enc or libheif converters don't work under gcc 10.2.1 anymore.
Compressing AV1 at quality 0.0...
Done compressing AV1 in just 747.32 seconds (27540 bytes)!
Compressing AV1 at quality 50.0...
Done compressing AV1 in just 884.79 seconds (470678 bytes)!
Compressing AV1 at quality 75.0...
Done compressing AV1 in just 985.09 seconds (882271 bytes)!
Compressing AV1 at quality 63.0...
Too bad that doesn't display compressed files AV1. If it is to be commercial of the new AOM C++11/17 google decoder instead of dav1d

opensource
https://www.sendspace.com/file/f4idpc

Thx for info LigH.