On Sat, Dec 14, 2024 at 6:39 PM Alexander Strasser via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote: > On 2024-12-14 11:09 +0100, Anton Khirnov wrote: > > Quoting Alexander Strasser via ffmpeg-devel (2024-12-01 21:13:56) > > > This is a fixed up version of the series I sent before.
IMO there would be no need to revert and then add the fixes. It would be preferable to have a new commit that does all of it at once, and maybe reference the reverted commit. But I don't think this patchset is the best approach. > > > This worked for me on Ubuntu 20.04 but probably will break > > > with older zlib versions as Hendrik pointed out in the > > > previous thread. Either we must update zlib on affected > > > FATE clients or add more .alt files to them as well. > > > > > > We could also go the further the "no_file_checksums" as > > > was demonstrated by James' series. > > > > > > I still prefer this way because it's simpler and retains > > > the value of the tests. > > > > This seems like a hack to me. > > Depends on what you precisely mean by hack. > It is a way to accommodate for shortcomings in older, but > still widely used zlib versions. > > > > We should not be testing for bitexact output from code that is not under > > our control and does not guarantee bitexactness. I agree with Anton. > Ideally! > > OTOH we also indirectly test that other code like C std lib functions > work as expected. > > In this case short of bugs in zlib/zlib-ng I do not see why the output > should differ with compression level 0. Maybe I'm missing something > I didn't look that deep into how zlib exactly works. The difference in the png tests comes from a bugfix in zlib itself: https://github.com/madler/zlib/commit/8ba393e7 I think the best approach would be Michael's "(c): implement enough of zlib ourselfs, so it can encode to a valid output" from another reply in this thread. We already have a partial zlib wrapper. It could be extended to write our own uncompressed data when compression_level is 0. It should be fairly straightforward and involve wrappers around deflate() and compress2(). Unfortunately I don't have time to look into this at the moment. Ramiro _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
