Print the item type in the diagnostic messages for missing mandatory
av1C or pixi property.

Before:
 * [Strict] Item ID 8 is missing mandatory pixi property

After:
 * [Strict] Item ID 8 of type 'grid' is missing mandatory pixi property

Signed-off-by: David Korczynski <david@adalogics.com>

matches findaom's behavior

fixes static linking of librav1e.a on windows since it requires bcrypt

Signed-off-by: Christopher Degawa <ccom@randomderp.com>

Signed-off-by: Christopher Degawa <ccom@randomderp.com>

Read/write y4m files row-by-row

The stride may not match the dimensions of the image.

Some headers such as glib-2.0 use identifier names that start with '_' followed by a capital letter.
The C standard reserves names beginning with an underscore and various other combinations.
ISO/IEC 9899:1999 (aka C99 standard) 7.1.3 Reserved identifiers

fuzz.sh is obsoleted by our engagement with oss-fuzz. fuzz.sh is trying
to invoke things that don't exist any more.

When building libavif for android using the NDK, the underlying
AV1 codec can be built for multiple architectures with specific
optimizations. It is useful to build them as it is sometimes
necessary to generate a fat APK (an APK that contains the library
for multiple architectures).

Upate the CMake file to include an architecture sub-directory while
finding libgav1. Also add a shell script that will clone and build
libgav1 using the andoroid NDK for the architectures supported on
Android by default.

… libavif to perform AVIF parsing without any AV1 codecs

Add JNI Bindings that can be used by android apps for AVIF decoding.
There are three functions that are exposed:
isAvifImage() and getInfo() and decode().

The README.md in the subdirectory contains instructions about how
to build the JNI wrapper and use it in an android app.

The Java class API can be found by going through the JavaDoc comments
in AvifDecoder.java

The following are the files of interest that need to be reviewed:
 * AvifDecoder.java - The Java interface for libavif.
 * build.gradle - Gradle build file for the java code.
 * libavif_jni.cc - The C++ file that interfaces between java and
                    libavif.
 * CMakeLists.txt - CMake file for building libavif_jni.cc and libavif.

All the other files in this commit are boilerplate files or scripts
generated by Android Studio.

Right now, we only have the header version of the license.

Some renderers will render the existing markdown incorrectly.

ScalePlane_12 only provide optimization for 2x scale up using
linear/bilinear filter (when scaling up, box and bilinear are the same),
and for the rest cases, it simply calls ScalePlane_16, which handles 2x
scale up just fine (slower though).

This optimization is thus optional and compilation can be allowed for
libyuv versions not providing it.

Fixes GH-781 (the function was introduced in libavif
46104d6).

…ed helper code (cJSON, compare)

Related: #684

The stride in bytes was mistaken for the number of samples to copy.

Some platforms (Android for example [1]) support only the F16 Half
Float format for images with bits-per-pixel == 16. This PR adds
support for converting the RGBA pixels into half float format.

It does so by adding a setting variable to avifRGBImage and then
doing the conversion at the end of avifImageYUVToRGB. It also
invokes libyuv if available to do the conversion with SIMD
optimizations.

While there is potential to make this even faster (instead of
doing this conversion in the end, we could potentially do it while
we do the YUV -> RGB conversion), that is a much larger change and
the performance gain from that may or may not be worth the trade
off in complicating the code paths.

[1] https://developer.android.com/reference/android/graphics/Bitmap.Config#RGBA_F16

libavif now supports conversion of RGBA pixels into F16 formats
for AVIF images with depths 10 and 12. Make use of that feature to
support RGBA_F16 bitmaps on the android JNI wrapper.

Note that apps can still pass an ARGB_8888 Bitmap for 10/12 bit
images and the wrapper will merely downscale them to 8 bits in that
case (existing behavior). Also as an added behavior, apps can now
pass RGBA_F16 bitmap for 8-bit images as well since libavif supports
converting 8-bit RGBA pixels to 16-bit half floats.

The SVT_AV1_VERSION_{MAJOR,MINOR,PATCHLEVEL} and SVT_AV1_CHECK_VERSION
macros were added in SVT-AV1 v0.9.0. Provide backup definition of these
macros for older versions of SVT-AV1.

Start to use the SVT_AV1_VERSION_{MAJOR,MINOR,PATCHLEVEL} macros. A
future commit will use the SVT_AV1_CHECK_VERSION macro.

Remove the temporary GCC pragma that ignores -Wunused-macros in
src/codec_svt.c. It was needed only before
commit 74a2144.

This reverts commit 1404989.

The commit broke compilation of src/codec_svt.c:

  libavif/src/codec_svt.c:8:10: fatal error: 'svt-av1/EbVersion.h' file not found
  #include "svt-av1/EbVersion.h"
           ^~~~~~~~~~~~~~~~~~~~~

Add the AVIF_RESULT_OUT_OF_MEMORY error code.

Add the avifArrayPop() function to remove the last element in the array.

Bug: #820.

To make the CI build work, I have to remove the line
      if: steps.cache-ext.outputs.cache-hit != 'true'
from the existing "uses: ilammy/setup-nasm@v1" step and the new
"name: Build SVT-AV1" step.

Fix #830.

The svt_av1_get_version() function was added in SVT-AV1 v0.9.0. Have
avifCodecVersionSvt() call svt_av1_get_version() for v0.9.0 or later.

Add an initial "v" to SVT_FULL_VERSION (now only used for versions older
than v0.9.0) to match the format of the string that
svt_av1_get_version() returns.

Fix a bug introduced in commit f732a4d.

In avifEncoderDataCreateItem(), increment data->lastItemID before
setting item->id equal to data->lastItemID. This is what the original
code did.

Fix #836.

Bug: #820

…sync frames

Related: https://crbug.com/1274200

It was possible to encode a 65x65 4:2:0 image with avifenc that could
not be decoded with avifdec. Calling avifAreGridDimensionsValid() from
both encoding and decoding pipelines removes this asymmetric behavior.

Add tests/avifgridapitest.c.

avifArrayPop() should zero the memory of the popped element. If we ever
push an element to the array, the memory of the new element will be all
zeros.

Assert that arr->count > 0 in avifArrayPop().

Also make sure we cast arr->elementSize to size_t when we multiply it by
another uint32_t variable.

The return type of avifDecoderReset() is avifResult, so it should not
return AVIF_FALSE on failure, because AVIF_FALSE has the same value (0)
as AVIF_RESULT_OK.

Allow avifDecoderDataCreateTile() to fail on avifImageCreateEmpty() or
avifCodecDecodeInputCreate() failures. Note that we don't check for
avifArrayPushPtr() failure yet. That will be done later.

Change all avifDecoderDataCreateTile() callers to handle its failures.

Bug: #820

Add avify4mtest.

Also describe ctest usage in CMakeLists.txt.

… CL in new avif tests

This also switches all plane looping and formatInfo querying blocks in y4m code/tests to use
consistent types and variable naming for intermediate variables (plane, planeCount, formatInfo).

The ISOBMFF and MIAF spec expects the values in big endian order.

When avifRWStreamWrite is called with uint32_t pointers on little
endian machines, we will end up writing incorrect values since the bytes
in uint32_t will be stored in little endian order in those machines.

For example, without this patch the "unityMatrix" field triggers the
following errors in ComplainceWarden (we end up writing 0x00000040
instead of 0x40000000):

[miaf][Rule #14] Error: Matrix field of the TrackHeaderBox: "a" value (100) shall b
e 0x00010000 or 0xFFFF0000
[miaf][Rule #14] Error: Matrix field of the TrackHeaderBox: "d" value (0) shall be
0x00010000 or 0xFFFF0000 ("b" is 0)
[miaf][Rule #14] Error: Matrix field of the TrackHeaderBox: "w" value (40) shall be 0x40000000

With this patch, these errors no longer appear.

The fix is to convert the uint32_t array into a uint8_t array and use
the correct big endian byte order for the values.

I have audited all the other calls to avifRWStreamWrite and this is
the only place where we use endian dependent parameters. In all the
other calls, we use a uint8_t pointer where there is no endian
depdendency.

Version 2 and version 3 of ItemInfoEntry differ only in the size of the
item_ID field:

    if (version >= 2) {
        if (version == 2) {
            unsigned int(16) item_ID;
        } else if (version == 3) {
            unsigned int(32) item_ID;
        }
	...
    }

In the rest of src/read.c, we already use the uint32_t type for item
IDs. So we only need to change avifParseItemInfoEntry().

Add the hiddenImage boolean field to the avifEncoderItem struct. When we
write the ItemInfoEntry boxes, if hiddenImage is true, set (flags & 1)
to 1.

Fix #851.

Section 7.2.3 of the HEIF spec:
The CodingConstraintsBox shall be present in the sample description
entry for tracks with handler_type equal to 'pict'.

The values of the fields are chosen to be permissive rather than
figuring out the exact values by inspecting the bitstream which can be
too cumbersome. The values are as follows:
all_ref_pics_intra - 0 - all samples can use any type of reference.
intra_pred_used - 1 - intra prediction may or may not be used.
max_ref_per_pic - 15 - reserved value to indicate that any number of
                       reference images can be used.

Fixes the following Compliance Warden error:
[heif][Rule #12] Error: CodingConstraintsBox ('ccst') shall be present
once

Section 10.3.1.1. of the HEIF spec:
It is required that 'iso8' is present among the compatible brands array.

Fixes the Compliance Warden error:
[heif][Rule #31] Error: 'msf1' brand: 'iso8' shall be present among the compatible brands array

Updates the libaom version checked out in the ext and docker scripts
from v3.2.0 to v3.3.0.