api: limit resolutions to be representable in a single ASS_Image

It appears plausible for the problem from
358770835248e26241e4796f38f02073a3bae252 to
affect more places in the rendering code.
However, for resolutions large enough to exhibit this
problem, there will likely be playback problems anyway.

Either API users will be unable to allocate a sufficiently large
buffer to blend into (> SIZE_MAX), or there will be issues during
playback with only parts of the subtitles actually being rendered
as larger events cannot create an ASS_Image (> INT_MAX).

Indeed a quick check reveals at least some truncations on floating point
to int conversion, although in this instance no OOB acceses occured.

  libass/ass_render.c:3040:35: runtime error: 3.27509e+09 is outside the range of representable values of type 'int'

Given this, the new limits seem unlikely to affect any valid use cases.

Thus limit the permissable frame size appropiately and
for consistency apply the same limit to storage size.
As a bonus and to avoid division by zero, both extents
will now always be set to zero if either one is invalid.

With this the check specific to BorderStyle=4 from
358770835248e26241e4796f38f02073a3bae252
is no longer needed, since its w and h are already
effectively limited to at most frame size.

0 files changed, 0 insertions, 0 deletions