On Thu, Feb 21, 2019 at 11:19:08AM +0100, Tomas Härdin wrote: > ons 2019-02-20 klockan 22:12 +0100 skrev Michael Niedermayer: > > On Sat, Feb 09, 2019 at 01:10:20PM +0000, Matthew Fearnley wrote: > > > - Improve block choices by counting 0-bytes in the entropy score > > > - Make histogram use uint16_t type, to allow byte counts from 16*16 > > > (current block size) up to 255*255 (maximum allowed 8bpp block size) > > > - Make sure score table is big enough for a full block's worth of bytes > > > - Calculate *xored without using code in inner loop > > > > This should have been split into multiple changes > > Alas >
> > compression seems to become slightly worse from this change > > > > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y > > test-old.avi > > ./ffmpeg -i matrixbench_mpeg2.mpg -vframes 30 -vcodec zmbv -an -y > > test-new.avi > > > > -rw-r----- 1 michael michael 1175466 Feb 20 22:06 test-new.avi > > -rw-r----- 1 michael michael 1174832 Feb 20 22:07 test-old.avi > > A whopping 0.05% change, no its just a tiny difference but i think it still would make sense to understand it. Generally a patch doing 4 improvments would be expected to improve things. This was not a hand picked case. I mean its not as if I saw 10 cases improving things and i picked the 11th. i looked at one case and that was worse Also either way the patch should have been split, dont you agree ? it also would make it much easier to within seconds identify which change actually caused the 0.05% difference. (maybe avoiding this discussion as it maybe would be obvious from that if this is a ommision in the commit message a bug a rare outlier ...) > with an MPEG source rather than the intended > PAL8.. The input to the encoder is always PAL8. so i assume you mean "old computer game material" vs. "realistic video". > > The flip side here is that we can now use larger block sizes and higher > me_range without crashing the encoder. We can add a slower mode that > tests a few different block sizes to see which one results in the > smallest output. > > /Tomas > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
