Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
> What about different samples? Not just single big one. I tried to pick representative sample. Which contains all kind of activities I usually do on my computer. Again: if you want, I can spend some time finding smaller samples without personal info (such that I can publish them) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
Op za 11 jun. 2022 01:37 schreef Аскар Сафин : > 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. > While the spec indeed mentions screen recording, it seems the kind of screen recording you do is probably not a use where ffv1 shines. The spec abstract starts with "This document defines FFV1, a lossless, intra-frame video encoding format." Notice "intra-frame". ffv1 does not do inter-frame decorrelation like most other codecs do. So, when compressing data with high inter-frame correlation, ffv1 doesn't do well. ffv1 does very well on for example film scans, when the presence of film grain makes inter-frame decorrelation of relatively little use. In screen captures where > 95% of the frame stays exactly the same, this approach doesn't work well indeed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
On Sat, Jun 11, 2022 at 1:37 AM Аскар Сафин 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 > What about different samples? Not just single big one. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
