[FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen

[Michael Niedermayer]

Hi

On Sat, Jun 11, 2022 at 02:37:19AM +0300, Аскар Сафин wrote:
> Hi. I use Debian Linux. I always capture my screen. I do this using my
> own program, which takes rgb24 frames from X server and saves them
> lossless in my own format. At fps 4
> (but duplicate frames are dropped). My codec is absolutely trivial
> (and lossless), it is based on ideas from QOI (
> https://github.com/phoboslab/qoi ) and QOV (
> https://github.com/wide-video/qov ).
> First I apply something like QOV encoding (with interframe coding) and
> then compress every frame using zstd with level 8. Surprisingly such
> trivial codec performs very well on my data.
> It gives better compress ratio than all lossless ffmpeg codecs I tried
> (x264, x265, vp9, av1, ffv1, ffvhuff, flv).
> 
> I write this not because I want to brag. I write this because it is
> possible that you will be interested in my ideas, that you will
> incorporate my ideas into your code.
> 
> ffv1 spec reads: "FFV1 is designed to support a wide range of lossless
> video applications such as... screen recording..." Unfortunately, ffv1
> turned out to be bad compared to my codec
> on screen recording data, so it is possible ffv1 could benefit from my ideas.
> 
> Now let me show you some data. I have a test video named
> "test-video-2022-05-16-17.mkv" in lossless x264 fullhd, which was
> captured from my screen. Uncompressed PAM size is
> 208,268,339,335 bytes (208.2 G). Unfortunately I cannot share it,
> because it contains a lot of my personal info. Now let me show you how
> different codecs perform on this file. All data
> was collected with this premises: pix_fmt is rgb24, everything is
> lossless, gop is 32, everything is on aws ec2 c3.4xlarge with 16
> cores, everything on Debian sid with sid's version of ffmpeg.
> 
> Codec: x264
> Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -pix_fmt rgb24
> -c:v libx264rgb -preset veryslow -qp 0 -threads 16 -g 32 /tmp/out.mkv
> Size: 2506211845 (~ 2.5 G)
> Time: 1218.22
> 
> Codec: ffv1
> Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -c:v ffv1
> -pix_fmt rgb24 -level 3 -threads 16 -g 32 -context 1 -slices 4 -coder
> -2 /tmp/o.mkv
> Size: 9431473324 (~9.4 G)
> Time: 1125.15
> 
> Codec: my codec (single threaded!)
> Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -c:v pam -pix_fmt
> rgb24 -f image2pipe pipe: < /dev/null | /tmp/nrdy encode 8 32
> Size: 1860479127 (~1.8 G)
> Time: 470.88
> 
> So, as you can see my codec beats ffv1 and x264 both by compress ratio
> and speed. Moreover, my single-threaded codec beats other
> multi-threads codecs by time. Are you interested?
> If yes, I can share my code. Of course, under some permissive license.
> Again: there is no any magic here, just something like QOV + zstd.
> Also, I can specially extract some sample
> from my videos, which doesn't contain personal info, and perform tests
> on this sample and publish sample

send a patch to libavcodec/ffv1*c

even better, add the interframe part independant of the residual coding
part so for each slice interframe can be choosen 
(like blank/intra, 0,0 MV, more optiond for future extension)
and residual coding (current FFV1, some LZ coder, ...)

why i suggest this, is because if you do, your code could become used
by alot of people. OTOH if you just post ideas nothing will likely happen.
There are many ideas about motion compensation and it didnt get cleanly 
integrated yet.

Also modular implementation in ffv1 would make alot of sense as we really
want to see what each individual part add compression/speed/complexity wise
so the overall codebase stays reasonable clean. We wouldnt want to support
10 algorithms if only 2 really make sense)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220611/9029cc24/attachment.sig>