tis 2024-06-11 klockan 10:16 +0200 skrev Andreas Rheinhardt: > 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 > )
Then I expect libx265 to fix it posthaste and push a new release, and for Debian etc to discourage installing versions prior to that as appropriate We can change the default of course (yolo!), but expect non-zero numbers of angry users whose workflows suddenly break /Tomas _______________________________________________ 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".
