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

Tomas Härdin tjoppen at acc.umu.se
Sun Jan 20 17:15:47 EET 2019


lör 2019-01-19 klockan 22:40 +0000 skrev Matthew Fearnley:
> > 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
> generally.

Huh, that's strange. Sounds like something that warrants a comment in
the code. I also see we have an answer do Carl's question: you're still
experimenting with this :) I think we can hold off on pushing anything
until you feel happy with the result

/Tomas


More information about the ffmpeg-devel mailing list