From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 4F50342A8A for ; Sat, 11 Jun 2022 15:24:46 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 04FCD68B2F6; Sat, 11 Jun 2022 18:24:44 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D2A8268A6B5 for ; Sat, 11 Jun 2022 18:24:36 +0300 (EEST) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id CFE6E20002 for ; Sat, 11 Jun 2022 15:24:35 +0000 (UTC) Date: Sat, 11 Jun 2022 17:24:34 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220611152434.GE396728@pb2> References: MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============6147884889947613088==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6147884889947613088== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3Prm0TOSGna1+iLx" Content-Disposition: inline --3Prm0TOSGna1+iLx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Sat, Jun 11, 2022 at 02:37:19AM +0300, =D0=90=D1=81=D0=BA=D0=B0=D1=80 = =D0=A1=D0=B0=D1=84=D0=B8=D0=BD 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). >=20 > 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. >=20 > 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 id= eas. >=20 > 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. >=20 > 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 >=20 > 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 >=20 > 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 >=20 > 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=20 (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=20 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 [...] --=20 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 --3Prm0TOSGna1+iLx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYqSzrgAKCRBhHseHBAsP q1olAJ9ouQm1mb+2K63UdS2KyixOka2UvACeIS8dUkAwsxsHPnqozubwBFMwRGA= =eOvK -----END PGP SIGNATURE----- --3Prm0TOSGna1+iLx-- --===============6147884889947613088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============6147884889947613088==--