[FFmpeg-devel] [PATCH 1/4] zmbvenc: don't sum the entropy when blocks are equal

Matthew Fearnley matthew.w.fearnley at gmail.com
Sun Jan 20 00:40:10 EET 2019

On Tue, 25 Dec 2018 at 09:35, Tomas Härdin <tjoppen at acc.umu.se> wrote:

> lör 2018-12-22 klockan 15:32 +0000 skrev Matthew Fearnley:
> > > > >
> > > > Note that bw,bh aren't guaranteed to equal ZMBV_BLOCK, so
> `histogram[0] ==
> > > > bw*bh` would have to be used to guard against those (literal) edge
> cases.
> > >
> > > Right, yes. But if we have block sizes other than ZMBV_BLOCK^2 then we
> > > need score tables for those sizes too.
> >
> > I’ve thought about that a bit. I wondered if it would be worth it given:
> > - the extra code, memory and logic needed
> If you have a huge amount of DOS captures to optimize then it might be
> worth it, else probably questionable
> > - it would only improve the edge blocks
> I imagine large blocks would be good for scenes with mostly global
> motion. You cut down on the number of MVs and thus the amount of data
> zlib has to compress, if the block size is a good fit.
> > - the existing score table isn’t catastrophically bad for short blocks,
> and would still favour blocks with more common pixels.
> >
> > It would be better from a correctness perspective though, and effects on
> running time should be negligible.
> Good point. There's also no telling whether the current model is
> actually an accurate prediction of how zlib behaves :)
Hi.  Just to say, I tried setting up additional score_tabs for the
bottom/right partial blocks.  Unfortunately, after implementing it and
ironing out the bugs, the new score tables actually caused a slight
increase in file size!
After a little informal investigation with a couple of videos, my findings
were that increasing the divisor - '(i / (double)(ZMBV_BLOCK * ZMBV_BLOCK *
some_factor))' - would generally lead to slight compression improvements.
Given the score table is still "valid" for smaller blocks, and given the
extra complexity of adding the score tables, plus the fact that it may
generally hurt the compression, I'm inclined to leave it with the one score
table.  But there may be potential to improve the current compression
method in future, by somehow tuning the divisor for better results


More information about the ffmpeg-devel mailing list