Webp < jxl

[jay123210599]

Check this out! I converted an APNG to a lossless animated webp using ffmpeg and a lossless animated jxl file using cjxl and the former was less than the latter! Amazing, right?

Test 1:

APNG: 470MB

Lossless animated WEBP: 131MB

JXL (effort 9): 194MB

Test 2:

APNG: 438MB

WEBP: 143MB

Lossless animated JXL (effort 9): 175MB

Commands used:

For WEBP:

ffmpeg -i input.apng -lossless 1 output.webp

For JXL:

cjxl input.apng -d 0 -e 9 output.jxl

The information from the videos I converted to APNG beforehand:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Format Range@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Bit rate : 10.1 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.203
Stream size : 1.67 GiB (87%)
Writing library : x265 3.0_Au+22-feec4bdf9866:[DJATOM's Mod][Linux][GCC 6.3.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=2 / numa-pools= / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / csv / csv-log-level=2 / input-csp=3 / input-res=1920x1080 / interlace=0 / total-frames=34120 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=240 / gop-lookahead=0 / bframes=9 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=2 / tu-intra-depth=2 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / limit-modes / me=2 / subme=5 / merange=48 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=1:-1 / no-sao / no-sao-non-deblock / rd=4 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=4.00 / no-rd-refine / no-lossless / cbqpoffs=4 / crqpoffs=4 / rc=crf / crf=15.0 / qcomp=0.72 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=0.85 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / hevc-aq / no-svt / qp-adaptation-range=2.00
Language : Japanese
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

The command I have used to convert them to APNGs:

ffmpeg -i -vf format=gbrp -plays 0 -c:v apng output.apng

https://www.mediafire.com/file/oi7pv6hbjcpsap9/Test_Files_and_Videos.7z/file

Well, what were the results? Did they all have the same colors? Were there any quality difference?

[Z2697]

WebP uses "differential" encoding.
see: webpmux -get frame 2 "Test 1.webp" -o 002.webp

[jay123210599]

WebP uses "differential" encoding.
see: webpmux -get frame 2 "Test 1.webp" -o 002.webp

How was the webp different from the apng and jxl, exactly? Did you try extracting 1 frame from each of them as png files and comparing them that way?

[Z2697]

If you do the extraction I told you you'll see.
I can only assume it's exactly the same based on the "lossless" because well the convenient way of converting from Animated WebP is basically non-existence, what worse is that differential coding just make it more difficult.

OK I'll just upload 2nd frame of that webp
https://i.slow.pics/ePdaUo1P.webp

[jay123210599]

I used ImageMagick's identify and this is what I got.

APNG:
https://imgur.com/JM9NvuI

JXL:
https://imgur.com/YGGod09

WEBP:
https://imgur.com/13x4vRC

[poisondeathray]

The posted apng, jpeg-xl , and webp are lossless for a converted to 8bit RGB format; but technically not lossless for a source 10bit444 YUV video

anim_dump can decode animated webp to an image sequence. ffmpeg still cannot do it but there are open tickets for this

lossless avif in RGB should be smaller e.g. using cpu-used 2 (lower values offer higher compression with diminishing returns, but slower to process)

lossless avif in 10bit444 YUV would be truly lossless for the source , and smaller . YUV also compresses better than RGB in general - that's why it's used for video . This plays ok in browsers, but higher overhead. Slow computers might lag, and legacy computers/browsers might not support avif

All of them are silly because you're making the filesize many times larger. If you wanted to share something... post the video

Test 1
source yuv444p10 4,496,079 bytes

apng rgb lossless 493,816,568 bytes
webp rgb lossless 137,974,458 bytes
avif rgb lossess (cpu-used 2) 95,375,685 bytes

avif yuv444p10 lossless (cpu-used 2) 73,163,539 bytes

[jay123210599]

lossless avif in RGB should be smaller e.g. using cpu-used 2 (lower values offer higher compression with diminishing returns, but slower to process)

lossless avif in 10bit444 YUV would be truly lossless for the source , and smaller . YUV also compresses better than RGB in general - that's why it's used for video . This plays ok in browsers, but higher overhead. Slow computers might lag, and legacy computers/browsers might not support avif

avif rgb lossess (cpu-used 2) 95,375,685 bytes

avif yuv444p10 lossless (cpu-used 2) 73,163,539 bytes

What where the commands you used to convert the apng and/or video to lossless rgb avif and lossless yuv444p10 avif?

[Z2697]

The posted apng, jpeg-xl , and webp are lossless for a converted to 8bit RGB format; but technically not lossless for a source 10bit444 YUV video

anim_dump can decode animated webp to an image sequence. ffmpeg still cannot do it but there are open tickets for this

lossless avif in RGB should be smaller e.g. using cpu-used 2 (lower values offer higher compression with diminishing returns, but slower to process)

lossless avif in 10bit444 YUV would be truly lossless for the source , and smaller . YUV also compresses better than RGB in general - that's why it's used for video . This plays ok in browsers, but higher overhead. Slow computers might lag, and legacy computers/browsers might not support avif

All of them are silly because you're making the filesize many times larger. If you wanted to share something... post the video

Test 1
source yuv444p10 4,496,079 bytes

apng rgb lossless 493,816,568 bytes
webp rgb lossless 137,974,458 bytes
avif rgb lossess (cpu-used 2) 95,375,685 bytes

avif yuv444p10 lossless (cpu-used 2) 73,163,539 bytes

Thanks for the tip. Somehow the anim_dump saves bgr directly as rgb LOL.
edit: probably WIC's fault, save to TIFF or PAM is safe.

[poisondeathray]

What where the commands you used to convert the apng and/or video to lossless rgb avif and lossless yuv444p10 avif?


There were some avif bugs in ffmpeg libavif about a year ago , but they look fixed now. You can squeeze out more compression by using lower cpu-used. Or if it's too slow for you, use higher values for less compression, higher speed


For yuv444p10


ffmpeg -i "Test 1.mkv" -c:v libaom-av1 -crf 0 -cpu-used 2 test1_yuv444p10.avif



For rgb, I used avs script input because the timestamps and timebase on that apng production are a bit off . If you're measuring "quality" using metrics, slightly off timestamps can produce different values and be detected as "different quality" (even if the decoded images are the same)

I used the apng instead of the video for the RGB source, because there are different ways of converting YUV to RGB, and even an tiny tiny fraction off will show up as "not lossless"


FFVideoSource("path\test 1.apng")
AssumeFPS(24000,1001)



ffmpeg -i test1apng.avs -c:v libaom-av1 -crf 0 -cpu-used 2 test1apngavs_ffmpeg_cpu2.avif

[jay123210599]

There were some avif bugs in ffmpeg libavif about a year ago , but they look fixed now. You can squeeze out more compression by using lower cpu-used. Or if it's too slow for you, use higher values for less compression, higher speed


For yuv444p10


ffmpeg -i "Test 1.mkv" -c:v libaom-av1 -crf 0 -cpu-used 2 test1_yuv444p10.avif


What were those bugs? What is the maximum value you can put in for cpu-used? It won't affect the quality of the avif?

[Z2697]

In fact the lossless compression ratio of x264 is higher than x265 and x265 is higher than libaom-av1
You get 70,896,451 bytes from the provided apng.
command line: ffmpeg -r 24 -i apng -c:v libx264rgb -qp 0 -preset 9 264

You can use -r before -i to force the framerate, if you like 24000/1001 you can do it as well. Not necessary to go AVS.
You can and probably should always force the framerate for both files when you calculating metric using FFmpeg.

https://files.catbox.moe/egvvt1.png

[poisondeathray]

What were those bugs? What is the maximum value you can put in for cpu-used? It won't affect the quality of the avif?

The bugs were posted in your other threads on the other forum about a year ago.


-cpu-used <int> E..V....... Quality/Speed ratio modifier (from -8 to 8) (default 1)


"Lossless" is always the same quality . -crf 0 is lossless for aom-av1 , so cpu-used only affects compression ratio (and processing speed)


In fact the lossless compression ratio of x264 is higher than x265 and x265 is higher than libaom-av1


He wants an animated image format for some reason (there is a bit of history on this, use search if you're interested, there are dozens of his threads with overlapping content on this topic). So that rules out x264, x265 . There is some work with HEIC, but it's poorly supported


You can use -r before -i to force the framerate, if you like 24000/1001 you can do it as well. Not necessary to go AVS.
You can and probably should always force the framerate for both files when you calculating metric using FFmpeg.



Yes, normally I do (if you read his old threads on the other forum, examples are posted) but it's necessary in this case because the you get garbage results with metrics like PSNR like 11db, even with forcing -r , with setpts and settb to normalize timebase for different containers. Try it . When you match the timestamps, timebase with avs input it's infinity for everything - the latter is the true result because when you decompress to raw RGB and compare they are identical


ffmpeg -r 24000/1001 -i "test 1.apng" -r 24000/1001 -i "test1apng_ffmpeg_cpu2.avif" -lavfi "[0:v]settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]psnr" -f null -




Input #0, apng, from 'test 1.apng':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: apng, rgb24(pc, gbr/bt709/bt709), 1920x1080 [SAR 1:1 DAR 1
6:9], 100k tbr, 100k tbn
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000022c3d23200] Stream #0: not enough frames to est
imate rate; consider increasing probesize
Input #1, mov,mp4,m4a,3gp,3g2,mj2, from 'test1apng_ffmpeg_cpu2.avif':
Metadata:
major_brand : avis
minor_version : 0
compatible_brands: avisavifmsf1iso8mif1miafMA1A
Duration: 00:00:06.51, start: 0.000000, bitrate: 117268 kb/s
Stream #1:0[0x1]: Video: av1 (libdav1d) (High) (av01 / 0x31307661), gbrp(pc, g
br/bt709/iec61966-2-1), 1920x1080 [SAR 1:1 DAR 16:9], 1 fps, 1 tbr, 1 tbn (defau
lt)
Metadata:
title : Color
Stream #1:1[0x1](und): Video: av1 (libdav1d) (High) (av01 / 0x31307661), gbrp(
pc, gbr/bt709/iec61966-2-1, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 117264 k
b/s, 23.98 fps, 23.98 tbr, 24k tbn (default)


[Parsed_psnr_4 @ 00000022c3d21e80] PSNR r:11.493180 g:11.701276 b:12.875624 average:11.982098 min:9.587521 max:inf



Normally the -r with settb and setpts will "fix" everything even between MP4, MKV containers . In this case you get garbage results

[Z2697]

I know his mind is set on this, I had replied to his old threads.

Normally the -r with settb and setpts will "fix" everything even between MP4, MKV containers . In this case you get garbage results

I just found the problem, FFmpeg recognizes the thumbnail of animated avif as the first stream and passes it to metrics filter. Use [1:v:1] in your example command line fixes that.
(AVIF or other animated HEIF is just a "plain" MP4 video file with a "image item" like thumbnail added to it.)

edit: But, how was the AVS script able to fix it?

By the way
There were some avif bugs in ffmpeg libavif about a year ago
What bugs? I'm curious too. Also I don't think FFmpeg ever uses libavif, they implemented the (de)muxer natively. (mudem? as an anology to codec - coder/decoder LOL)

[poisondeathray]

I know his mind is set on this, I had replied to his old threads.

Yeah, but not the dozens(!) of other similar threads on the videohelp forum. I think he's here because he got banned for that... In the old days with the old mods - he would have been banned here for numerous rule violations. They used to be waaay more strict at d9




I just found the problem, FFmpeg recognizes the thumbnail of avif as the first stream and passes it to metrics filter. Use [1:v:1] in your example command line fixes that.


nice


edit: But, how was the AVS script able to fix it?

It works for avs, because only 1 stream is frameserved to ffmpeg



What bugs? I'm curious too. Also I don't think FFmpeg ever uses libavif, they implemented the (de)muxer natively. (mudem? as an anology to codec - coder/decoder LOL)

The problem before was the ffmpeg produced avif's didn't animate in browser - IIRC there was some tags missing that broke libavif spec