[FFmpeg-devel] [PATCH v2 0/3] Make fate tests succeed with zlib-ng

[Michael Niedermayer]

Hi

On Mon, Dec 16, 2024 at 05:39:22PM -0500, Leo Izen wrote:
[...]

> Essentially, we shouldn't be having FATE failures

agree


> depend on the specific
> behavior of whatever zlib we link to, provided it's correct.
> DEFLATE
> promises certain things about its encodes, but one of the things DEFLATE
> does not promise is that the same uncompressed data always encodes to the
> same compressed data. When we check the CRC of e.g. PNG files, we
> erroneously assume this, and we just basically never got called on it
> because nearly every system uses a recent version of stock zlib.
> 
> Anton is basically saying that if we want to compare the CRC of zlib output,
> trying to compile a list of different zlib versions and making reference
> files of each one doesn't really solve the underlying problem, and it's kind
> of hacky.
> 

> Solutions I can think of to this problem that solve it forever would be to
> (a): not compare the checksums of encoded files with zlib chunks
> OR
> (b): have some sort of tool that decodes relevant zlib chunks and then run a
> checksum on its output

(c): implement enough of zlib ourselfs, so it can encode to a valid output
(d): Find a input that encodes identically with all existing zlib variants
(e): Find a input that encodes to max 2 variants and store 2 checksums

I dont think (e) is the best solution, but if it works for all cases,
my point is, that it is a valid solution

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20241216/3602d43b/attachment.sig>