[FFmpeg-devel] [PATCH v2] fate: skip encoded output hashing for tests that depend on zlib

[Michael Niedermayer]

On Sat, Oct 19, 2024 at 07:22:23PM -0300, James Almer wrote:
> On 10/19/2024 7:09 PM, Michael Niedermayer wrote:
> > On Sat, Oct 19, 2024 at 10:33:58AM -0300, James Almer wrote:
> > > As there's no guarantee that the output will be exactly the same across implementations,
> > > just don't test it at all.
> > > 
> > > Signed-off-by: James Almer <jamrial at gmail.com>
> > 
> > not objecting to this patch but
> > 
> > inflate is 550 lines of code
> > "Entire inflater (including optional zlib header parsing and Adler-32 checking) is implemented in a single function as a coroutine, which is separately available in a small (~550 line) source file: miniz_tinfl.c"
> > 
> > how much code do we need to write a simple store (not compress) ?
> > if i naively assume that decode must suport everything and encode
> > only one case that it chooses, iam perplexed how we still depend
> > on zlib for simply storing uncompressed zlib formated data
> 
> Well, nobody sets compression_level to 0 when encoding png or anything in
> any real world scenario, and this wasn't an issue until zlib-ng showed up.
> But yes, a native uncompressed deflate() implementation was suggested, but
> nobody volunteered for it.

well, it doesnt have to be "uncompressed" if that attracts more interrest ;)

beat zlib and zlib-ng in compression if you must

thx

[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell
-------------- 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/20241020/6d4402a8/attachment.sig>