[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