Sure; no-copy padding was broken for some scenarios (namely, left-padding when target height divides evenly by 32). Lets say I want to use following filter string: "scale=720x576, pad=880:576:80:0" (scale to 720x576 and add some black bands on the sides). Pad should be able to allocate buffer for scale and then just fill remaining area; yet it fails to do so and "Direct padding impossible allocating new frame" message can be seen in logs (when log level set to verbose). In this particular case the allocated buffer is big enough to hold 896x576 image and a few extra bytes; scale filter then operates on its view of the buffer (720x576 but with pitch of 896). Interestingly, last row of that view doesn't fit in the buffer (there's only 720 bytes + a bit of padding and not 880 bytes). So scale does its thing and then pad checks if there is enough extra space in the buffer for the padding. There's not; in fact there's no room in the buffer to hold the view itself - so pad gives up and does another allocation and a copy. So, basically this patch fixes that.
2016-01-06 0:59 GMT+03:00 Paul B Mahol <one...@gmail.com>: > On 1/5/16, Andrey Turkin <andrey.tur...@gmail.com> wrote: > > > > One extra line must be allocated when adding left padding to make sure > > that last line in every plane fits in the allocated buffer fully > > --- > > libavfilter/vf_pad.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Do you have example this patch fixes? > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
