+
+ In addition to these concerns, we may read/write as much as a whole extra line
+ at the end of each plane in cases where we are messing with offsets in order to
+ do pad or crop. To solve this we over-allocate by an extra _stride[i] bytes.
+
+ As an example: we may write to images starting at an offset so we get some padding.
+ Hence we want to write in the following pattern:
+
+ block start write start line end
+ |..(padding)..|<------line-size------------->|..(padding)..|
+ |..(padding)..|<------line-size------------->|..(padding)..|
+ |..(padding)..|<------line-size------------->|..(padding)..|
+
+ where line-size is of the smaller (inter_size) image and the full padded line length is that of
+ out_size. To get things to work we have to tell FFmpeg that the stride is that of out_size.
+ However some parts of FFmpeg (notably rgb48Toxyz12 in swscale.c) process data for the full
+ specified *stride*. This does not matter until we get to the last line:
+
+ block start write start line end
+ |..(padding)..|<------line-size------------->|XXXwrittenXXX|
+ |XXXwrittenXXX|<------line-size------------->|XXXwrittenXXX|
+ |XXXwrittenXXX|<------line-size------------->|XXXwrittenXXXXXXwrittenXXX
+ ^^^^ out of bounds
+ */
+ _data[i] = (uint8_t *) wrapped_av_malloc (_stride[i] * (sample_size(i).height + 1) + 32);
+#if HAVE_VALGRIND_MEMCHECK_H
+ /* The data between the end of the line size and the stride is undefined but processed by
+ libswscale, causing lots of valgrind errors. Mark it all defined to quell these errors.