Tomas Härdin: > tis 2024-06-11 klockan 10:05 +0200 skrev Andreas Rheinhardt: >> Tomas Härdin: >>> tis 2024-06-11 klockan 09:42 +0200 skrev Andreas Rheinhardt: >>>> The SEI handling of libx265 is buggy and can easily lead >>>> to memory corruption: It reuses certain buffers, but when >>>> reusing them it presumes that it is enough for these buffers >>>> to exist and does not check whether they are actually large >>>> enough to hold what is intended to be stored in them.* >>>> >>>> Our users are exposed to this because forwarding A53 CC data >>>> is enabled by default. Change this to make it disabled >>>> by default. >>>> >>>> "Fixes" tickets #9666, #10411, #11052 and (presumably) #10906. >>> >>> Shouldn't users use non-buggy versions of libx26? I've had people >>> ask >>> about CC, and I'm sure many users would be annoyed at them suddenly >>> breaking. I suggest complaining loudly at compile time and/or when >>> loading libx265 instead >> >> Non-buggy versions of libx265? People use what they have because it >> exists. > > What I'm getting at is that this is libx265's responsibility, and the > responsibility of packagers not to ship broken versions of it. Does all > A53 CCs break with the present libx265 bug or only some? >
1. There is no version of libx265 with this bug fixed (the bug itself is here: https://bitbucket.org/multicoreware/x265_git/src/8787e87020d77416f0ff0b7f3c97ac8b90332c31/source/encoder/encoder.cpp#lines-1086:1117) 2. The issue can happen when a later frame uses larger SEIs or more SEIs than an earlier frame. Because x265 thinks that every buffer that exists can handle an arbitrary amount of data. - Andreas _______________________________________________ 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".
