[FFmpeg-devel] [PATCH] libavcodec/zmbvenc: Add support for RGB formats

[Tomas Härdin]

tor 2019-03-07 klockan 14:42 +0000 skrev Matthew Fearnley:
> This consists mostly of the following changes:
> - add newly supported pixel formats (RGB555LE, RGB565LE, BGR0)
> - select the ZMBV format (c->fmt) and bytes per pixel (c->bypp) based on
>   avctx->pix_fmt
> - multiply widths/x-values by c->bypp, in places where bytes, not pixels, are
>   expected
> - disable palette-writing code for non-palette pix_fmts
> - make a note about histogram[]'s datatype (it could need increasing if
>   ZMBV_BLOCK is increased)
> - adjust the c->score_tab length to take up to (and including) 4 times the
>   number of pixels in a block
> - initialise c->score_tab up to c->bypp * the number of pixels
> 
> Note: the ZmbvFormat enum allows for additional bit depths:
> - 1,2,4-bit (palette)
> - 24-bit (RGB)
> 
> At time of writing the specifics of these (e.g. channel order, bit alignment)
> are not currently defined, and DOSBox only implements support for 8/15/16/32
> bpp.
> One might expect the 24-bit format - if implemented - to be BGR24, to have the
> same channel order as BGR0.
> However, the decoder in zmbv.c has been guessed to use RGB24, so I have chosen
> to not contradict this, and omitted specific support for this format.

Sounds good. Maybe we could coordinate 1/2/4/24-bit support with the
dosbox devs? And maybe we should do something about the RGB24 thing in
the decoder..

It seems the decoder performs quite well. I did a little test with
different me_range for the three not-broken zmbv samples in FATE:

  $ for RANGE in 1 2 4 8 16 24 32; do mkdir -p zmbv/$RANGE ; for f in
fate-suite/zmbv/zmbv_*.avi ; do ./ffmpeg -i $f -y -vcodec zmbv
-me_range $RANGE zmbv/$RANGE/$(basename $f) ; done ; done
  $ cd zmbv && du --bytes --max-depth=1 | sort -n
  501874  ./32
  508140  ./24
  513372  ./16
  524550  ./8
  533856  ./4
  548282  ./2
  653010  ./fate  <-- original samples
  735854  ./1

So even -me_range 2 outperforms whatever encoder produced the samples.

Maybe future work could be to try to figure out the optimal block size
based on some heuristic?

Patch looks good to me.

/Tomas