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

Matthew Fearnley matthew.w.fearnley at gmail.com
Thu Feb 21 16:08:44 EET 2019


On Thu, 21 Feb 2019 at 10:26, Tomas Härdin <tjoppen at acc.umu.se> wrote:

> 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.
>

I know the DEFLATE format fairly well, and a dummy DEFLATE implementation
would certainly be possible.

An uncompressed block can be up to 65535 bytes, and has a simple five-byte
header (subject to some bit alignment issues, but they only come into play
when other block types are also used).

Here's a simple code example, the guts of which fit into <70 lines:
https://gist.github.com/countingpine/602453d330ea055a4bcab90ca2a7ed02

It allows data to be compressed in chunks, allowing a stream to be split
across frames, like in ZMBV.
The first chunk needs the START flag, and the last chunk (if any) needs the
FINISH flag.

It also allows adding an Adler32 checksum - although ZMBV itself doesn't
need this, because it never "finishes" the stream.

The question would still remain though, of the best way to incorporate it
into FFMEG.  That's probably beyond my current knowledge..

Matthew


/Tomas
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list