[FFmpeg-trac] #8475(avfilter:new): pad filter fails in certain edge cases because of rounding
FFmpeg
trac at avcodec.org
Thu Jan 16 02:39:09 EET 2020
#8475: pad filter fails in certain edge cases because of rounding
-------------------------------------+-------------------------------------
Reporter: imiddle | Type: defect
Status: new | Priority: normal
Component: avfilter | Version: git-
Keywords: pad filter | master
rounding | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
In certain cases, the `pad` filter fails to configure itself properly.
Here's an example, using imagemagick to create an appropriate test file:
{{{
$ convert -size 15x15 xc:red -sampling-factor 4:2:0 red.jpg
$ ffmpeg -i red.jpg -vf pad=iw+16:ih+16:ow-iw:oh-ih pad.png
...
...Input area 16:16:31:31 not within the padded area 0:0:30:30...
}}}
It seems like `ow-iw` and `oh-ih` should always work as values of `x` and
`y`; this should put the image in the lower right corner.
The failure occurs because the values of `w:h:x:y` are first computed as
`31:31:16:16` and then rounded down (via `ff_draw_round_to_sub`) to
`30:30:16:16` due to chroma considerations. Since the values of `w` and
`h` have shrunk but `x` and `y` have not, the image is no longer validly
placed.
A possible solution is to round off `w` and `h` before evaluating `x` and
`y`. In my example, this would result in `w:h` being evaluated as `31:31`
and rounded to `30:30`, then `x:y` being evaluated as `15:15` and rounded
to `14:14`.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8475>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list