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 22nd November 2020, 17:19   #341  |  Link
paul97
Registered User
 
Join Date: Mar 2018
Posts: 12
Jamaika, is it that commit ?
https://chromium.googlesource.com/co...f0aee3fbe02e84
Friday November 20th
paul97 is offline   Reply With Quote
Old 22nd November 2020, 17:24   #342  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
Yes the same
https://www.sendspace.com/file/3glokx
Jamaika is offline   Reply With Quote
Old 25th November 2020, 07:46   #343  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
New codecs, untestet with bugs fixed 25.11.2020
https://www.sendspace.com/file/dbx3jx
Jamaika is offline   Reply With Quote
Old 28th November 2020, 14:02   #344  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
New codecs 27/11/2020

Code:
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
Code:
VVCSoftware: VTM Encoder Version 11.0rc1-8157466c [Windows][GCC 10.2.1][64 bit] [SIMD=NONE]
VVCSoftware: HDRTools Version 0.20-0db34fbc
Code:
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
Code:
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:
Code:
defined(_MSC_VER) && _MSC_VER >= 1900
let's change to
Code:
(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?
Code:
#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
Code:
#  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.

Last edited by Jamaika; 28th November 2020 at 14:39.
Jamaika is offline   Reply With Quote
Old 28th November 2020, 17:15   #345  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,328
Quote:
Originally Posted by Jamaika View Post
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...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th November 2020, 17:44   #346  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
Quote:
Originally Posted by LigH View Post
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.
Jamaika is offline   Reply With Quote
Old 3rd December 2020, 14:11   #347  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 79
Quote:
Originally Posted by Jamaika View Post
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.
.
Quote:
Originally Posted by Jamaika View Post
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.
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 3rd December 2020 at 14:20.
Marsu42 is offline   Reply With Quote
Old 4th December 2020, 09:06   #348  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
help comparison of photo codecs

Last edited by Jamaika; 6th December 2020 at 21:50.
Jamaika is offline   Reply With Quote
Old 4th December 2020, 10:24   #349  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
Quote:
Originally Posted by Marsu42 View Post
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.
Jamaika is offline   Reply With Quote
Old 4th December 2020, 14:19   #350  |  Link
Thundik81
Registered User
 
Join Date: Jul 2004
Posts: 15
Quote:
Originally Posted by Jamaika View Post
help comparison of photo codecs
[3.82 Mo]
Use pingo!
Thundik81 is offline   Reply With Quote
Old 4th December 2020, 22:26   #351  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,556
Quote:
Originally Posted by Marsu42 View Post
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.
foxyshadis is offline   Reply With Quote
Old 5th December 2020, 08:01   #352  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
Quote:
Originally Posted by foxyshadis View Post
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

Last edited by Jamaika; 5th December 2020 at 08:07.
Jamaika is offline   Reply With Quote
Old 5th December 2020, 08:13   #353  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
New codecs 04/12/2020

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

Last edited by Jamaika; 6th December 2020 at 22:02.
Jamaika is offline   Reply With Quote
Old 7th December 2020, 17:24   #354  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 79
Quote:
Originally Posted by foxyshadis View Post
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?
Code:
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.
__________________
"The innocent have nothing to fear" :stupid:
Marsu42 is offline   Reply With Quote
Old 7th December 2020, 20:18   #355  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
Quote:
Originally Posted by Marsu42 View Post
I
The heic result with libheif is strange, maybe I'm doing something wrong?
Code:
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.
Code:
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

Last edited by Jamaika; 7th December 2020 at 22:34.
Jamaika is offline   Reply With Quote
Old 8th December 2020, 08:18   #356  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,328
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).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 8th December 2020, 12:30   #357  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 79
Quote:
Originally Posted by Jamaika View Post
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 :-\

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

Last edited by Marsu42; 8th December 2020 at 12:53.
Marsu42 is offline   Reply With Quote
Old 9th December 2020, 22:20   #358  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
Quote:
Originally Posted by Marsu42 View Post
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.
Code:
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
Code:
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
Code:
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

Last edited by Jamaika; 10th December 2020 at 10:27.
Jamaika is offline   Reply With Quote
Old 11th December 2020, 11:37   #359  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,328
I hope you can spare a little time to support MABS supporting the HHI VVC codecs, explaining your patches there.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 12th December 2020 at 16:38.
LigH is offline   Reply With Quote
Old 11th December 2020, 20:19   #360  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 777
New codecs 04/12/2020

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

Last edited by Jamaika; 14th December 2020 at 09:25.
Jamaika 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 07:55.


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