tor 2019-02-21 klockan 15:26 +0100 skrev Carl Eugen Hoyos: > > 2019-02-21 11:26 GMT+01:00, Tomas Härdin <tjop...@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 <tjop...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
