Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encoder and decoder support of large image size #2271

Open
wantehchang opened this issue Jul 15, 2024 · 2 comments
Open

Encoder and decoder support of large image size #2271

wantehchang opened this issue Jul 15, 2024 · 2 comments

Comments

@wantehchang
Copy link
Collaborator

wantehchang commented Jul 15, 2024

This issue tracks the work to allow the libavif encoder and decoder to support larger image size.

Note that it requires an AV1 codec that supports large frame size. For example, this is libaom's issue on encoder support of large frame size: https://aomedia.issues.chromium.org/issues/353371270

wantehchang added a commit to wantehchang/libavif that referenced this issue Jul 16, 2024
Pass UINT32_MAX as the imageSizeLimit argument to avifReadImage().

Bug: AOMediaCodec#2271
@wantehchang
Copy link
Collaborator Author

@jzern @vrabaud @y-guyon

Here is a representative example of (unsigned) integer overflow, taken from avifpng.c. Note that rgb.rowBytes is of the uint32_t type.

     for (uint32_t y = 0; y < rgb.height; ++y) {
         rowPointers[y] = &rgb.pixels[y * rgb.rowBytes];
     }

There are three ways to fix this.

  1. Add a size_t cast to y or rgb.rowBytes:
     for (uint32_t y = 0; y < rgb.height; ++y) {
         rowPointers[y] = &rgb.pixels[(size_t)y * rgb.rowBytes];
     }
  1. Declare the loop index variable y as size_t:
     for (size_t y = 0; y < rgb.height; ++y) {
         rowPointers[y] = &rgb.pixels[y * rgb.rowBytes];
     }
  1. Replace the multiplication with addition of a pointer variable with rgb.rowBytes:
     uint8_t * rgbRow = rgb.pixels;
     for (uint32_t y = 0; y < rgb.height; ++y) {
         rowPointers[y] = rgbRow;
         rgbRow += rgb.rowBytes;
     }

Which solution do you prefer?

I prefer solution 3, because it is also a form of optimization ("strength reduction"). It requires more changes.

@y-guyon
Copy link
Collaborator

y-guyon commented Jul 17, 2024

I prefer solution 3 too.

wantehchang added a commit to wantehchang/libavif that referenced this issue Jul 17, 2024
Replace multiplication with rgb.rowBytes with addition of rgb.rowBytes
to a row pointer in a loop.

Related to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Jul 17, 2024
Replace multiplication with rgb.rowBytes with addition of rgb.rowBytes
to a row pointer in a loop.

Related to AOMediaCodec#2271.
wantehchang added a commit that referenced this issue Jul 26, 2024
Replace multiplication with rgb.rowBytes with addition of rgb.rowBytes
to a row pointer in a loop.

Related to #2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Jul 30, 2024
Pass UINT32_MAX as the imageSizeLimit argument to avifReadImage().

Bug: AOMediaCodec#2271
wantehchang added a commit that referenced this issue Jul 30, 2024
Pass UINT32_MAX as the imageSizeLimit argument to avifReadImage() and
y4mRead().

Bug: #2271
wantehchang added a commit to wantehchang/libavif that referenced this issue Jul 31, 2024
Replace multiplication with rgb.rowBytes with addition of rgb.rowBytes
to a row pointer in a loop.

Related to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 1, 2024
Calculate rowBytes in uint32_t. Only the allocation size needs to be
size_t.

Also make sure it is safe to cast various rowBytes fields to ptrdiff_t.
We need to do this when subtracting rowBytes from a pointer to go back
one row.

Part of the fix to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 1, 2024
Fix overflows when multiplying with rowBytes in avifImageRGBToYUV() and
avifImageYUVAnyToRGBAnySlow(), by storing the various uint32_t rowBytes
fields in local variables of the size_t type. Then multiplications with
the size_t rowBytes local variables will be done in size_t.

Part of the fix to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 1, 2024
Fix overflows when multiplying with rowBytes in avifImageRGBToYUV() and
avifImageYUVAnyToRGBAnySlow(), by storing the various uint32_t rowBytes
fields in local variables of the size_t type. Then multiplications with
the size_t rowBytes local variables will be done in size_t.

Part of the fix to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 1, 2024
Fix overflows when multiplying with rowBytes in avifImageRGBToYUV() and
avifImageYUVAnyToRGBAnySlow(), by storing the various uint32_t rowBytes
fields in local variables of the size_t type. Then multiplications with
the size_t rowBytes local variables will be done in size_t.

Part of the fix to AOMediaCodec#2271.
wantehchang added a commit that referenced this issue Aug 1, 2024
Calculate rowBytes in uint32_t. Only the allocation size needs to be
size_t.

Also make sure it is safe to cast various rowBytes fields to ptrdiff_t.
We need to do this when subtracting rowBytes from a pointer to go back
one row.

Part of the fix to #2271.
wantehchang added a commit that referenced this issue Aug 1, 2024
Replace multiplication with rgb.rowBytes with addition of rgb.rowBytes
to a row pointer in a loop.

Related to #2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 2, 2024
Fix overflows when multiplying with rowBytes in avifImageRGBToYUV(), by
storing the various uint32_t rowBytes fields in local variables of the
size_t type. Then multiplications with the size_t rowBytes local
variables will be done in size_t.

Part of the fix to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 6, 2024
The width, height, and stride parameters of libyuv and libsharpyuv
functions are all of the int type. The corresponding fields in libavif
are of the uint32_t type. So we need to check if it is safe to pass the
libavif uint32_t values to libyuv and libsharpyuv.

Related to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 6, 2024
The width, height, and stride parameters of libyuv and libsharpyuv
functions are all of the int type. The corresponding fields in libavif
are of the uint32_t type. So we need to check if it is safe to pass the
libavif uint32_t values to libyuv and libsharpyuv.

Related to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 6, 2024
The width, height, and stride parameters of libyuv and libsharpyuv
functions are all of the int type. The corresponding fields in libavif
are of the uint32_t type. So we need to check if it is safe to pass the
libavif uint32_t values to libyuv and libsharpyuv.

Related to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 6, 2024
The width, height, and stride parameters of libyuv and libsharpyuv
functions are all of the int type. The corresponding fields in libavif
are of the uint32_t type. So we need to check if it is safe to pass the
libavif uint32_t values to libyuv and libsharpyuv.

Related to AOMediaCodec#2271.
wantehchang added a commit to wantehchang/libavif that referenced this issue Aug 6, 2024
The width, height, and stride parameters of libyuv and libsharpyuv
functions are all of the int type. The corresponding fields in libavif
are of the uint32_t type. So we need to check if it is safe to pass the
libavif uint32_t values to libyuv and libsharpyuv.

Related to AOMediaCodec#2271.
wantehchang added a commit that referenced this issue Aug 8, 2024
The width, height, and stride parameters of libyuv and libsharpyuv
functions are all of the int type. The corresponding fields in libavif
are of the uint32_t type. So we need to check if it is safe to pass the
libavif uint32_t values to libyuv and libsharpyuv.

Related to #2271.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants