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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
