On 12/16/24 5:50 PM, Michael Niedermayer wrote:
(c): implement enough of zlib ourselfs, so it can encode to a valid output
A reimplementation of zlib that does nothing except for fixing FATE failures that shouldn't be failing anyway sounds like a security vulnerability waiting to happen. Stock maddler's zlib still has vulnerabilities occur and there's the whole world's eyes on it. This sounds like a bad idea.
Also this sounds like solving an XY problem, if differing zlib implementations are causing fate to fail, maybe we should not depend on a specific zlib implementation rather than NIH'ing our own.
(d): Find a input that encodes identically with all existing zlib variants
Doesn't fix the problem, which is that need to be aware of all the known variants and create hacks to work with them instead of doing something more future proof.
(e): Find a input that encodes to max 2 variants and store 2 checksums
Doesn't fix the problem, which is that need to be aware of all the known variants and create hacks to work with them instead of doing something more future proof.
I dont think (e) is the best solution, but if it works for all cases, my point is, that it is a valid solution
It really isn't, because it doesn't work in all cases. It works for a specific list of known cases. This is not the same thing.
- Leo Izen (Traneptora) _______________________________________________ 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".
