[FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

[Tomas Härdin]

tor 2019-02-21 klockan 15:26 +0100 skrev Carl Eugen Hoyos:
> > 2019-02-21 11:26 GMT+01:00, Tomas Härdin <tjoppen at acc.umu.se>:
> > ons 2019-02-20 klockan 23:33 +0100 skrev Carl Eugen Hoyos:
> > > > > > > > 2019-02-10 16:42 GMT+01:00, Tomas Härdin <tjoppen at acc.umu.se>:
> > > > lör 2019-02-09 klockan 13:10 +0000 skrev Matthew Fearnley:
> > > > > - 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
> > > > > ---
> > > > >  libavcodec/zmbvenc.c | 22 ++++++++++++++++------
> > > > >  1 file changed, 16 insertions(+), 6 deletions(-)
> > > > 
> > > > Passes FATE, looks good to me
> > > 
> > > I believe you asked on irc about fate tests:
> > > Since such a test would depend on the zlib version, you cannot test
> > > exact output, you could only test a round-trip (assuming the codec
> > > really is lossless).
> > 
> > Right, we'd need to embed a specific version of zlib. But we probably
> > don't want to do that, for many reasons.
> > 
> > A dummy DEFLATE implementation that just passes the bytes along could
> > be useful. I know there's a mode in the DEFLATE format for blocks that
> > fail to compress. That way we could test many encoders that depend on
> > zlib, and their output should decode just fine.
> 
> What's wrong with a round-trip test?

Nothing I suppose. But it might be nice to catch unintended changes to
the encoder's output

/Tomas