summaryrefslogtreecommitdiffstats
path: root/libmpv/render.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-09-17 15:20:08 +0200
committerwm4 <wm4@nowhere>2020-09-17 15:24:27 +0200
commit083adf97e14f3996f3c5c54b418de9cc5905b027 (patch)
tree35b599efe63eb4c31cccee0539bf8355a610796d /libmpv/render.h
parentb2f4320d06304f16a3f447e7e68cab54b670bef1 (diff)
downloadmpv-083adf97e14f3996f3c5c54b418de9cc5905b027.tar.bz2
mpv-083adf97e14f3996f3c5c54b418de9cc5905b027.tar.xz
sws_utils: work around libswscale corrupting memory yet again
If the alignment is less than 16, certain libswscale code paths will silently corrupt memory outside of the target buffer. This actually affected the libmpv software rendering API (that was fun to debug). Rather than passing this problem to the next API user, try to avoid it within libmpv. It's unclear which alignment libswscale requires for safe operation. I'm picking 32 (one more than the observed safe value in the case I experienced), because libavfilter mostly uses this value. The way to work this around is slow: just make a full copy of the entire input or output image. Possibly this could be optimized by using the slice API, but that would be more effort, and would likely expose further libswscale bugs. Hope that this is a rarely needed path. The next commit will update the alignment requirement documentation bits.
Diffstat (limited to 'libmpv/render.h')
0 files changed, 0 insertions, 0 deletions