Compilation fails with -Werror=format compiling vaapi on 32bit

[goffioul]

When compiling ffmpeg 5.1.2 with AOSP (seen with Android-11 and Android-13) for x86 (32bits), I reach the following compilation error:

external/ffmpeg/libavutil/hwcontext_vaapi.c:1188:34: error: incompatible pointer types assigning to 'uintptr_t *' (aka 'unsigned int *') from 'unsigned long *' [-Werr
or,-Wincompatible-pointer-types]
        buffer_desc.buffers      = &buffer_handle;
                                 ^ ~~~~~~~~~~~~~~
external/ffmpeg/libavutil/hwcontext_vaapi.c:1488:12: error: format specifies type 'long' but the argument has type 'uintptr_t' (aka 'unsigned int') [-Werror,-Wformat]
           mapping->buffer_info.handle);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~

[Carl Eugen Hoyos]

Please test current FFmpeg git head, the only version supported on this bug tracker, and please provide the configure line you tested and the NDK version.

[goffioul]

As the relevant code in libavutil/hwcontext_vaapi.c hasn't changed between 5.1.2 and current git head, the issue is still present there. It is also not specific to Android, you just need the following combination: 32 bits + VA-API + libdrm.

So using current git head (65f96a965af415300f7533c75940eeae4e3a2287) and the following configure line on Linux (Fedora 35, gcc 11.3.1):

PKG_CONFIG_PATH=/usr/lib/pkgconfig ../configure \
    --disable-static --enable-shared \
    --arch=x86 --cpu=i686 --build_suffix= \
    --extra-cflags=-m32 --extra-ldflags=-m32 --disable-x86asm \
    --extra-cflags=-Werror=incompatible-pointer-types \
    --extra-cflags=-Werror=format \
    --enable-libdrm

you reach the same compilation error:

CC	libavutil/hwcontext_vaapi.o
src/libavutil/hwcontext_vaapi.c: In function ‘vaapi_map_from_drm’:
src/libavutil/hwcontext_vaapi.c:1216:34: error: assignment to ‘uintptr_t *’ {aka ‘unsigned int *’} from incompatible pointer type ‘long unsigned int *’ [-Werror=incompatible-pointer-types]
 1216 |         buffer_desc.buffers      = &buffer_handle;
      |                                  ^
src/libavutil/hwcontext_vaapi.c: In function ‘vaapi_map_to_drm_abh’:
src/libavutil/hwcontext_vaapi.c:1514:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘uintptr_t’ {aka ‘unsigned int’} [-Werror=format=]
 1514 |     av_log(hwfc, AV_LOG_DEBUG, "DRM PRIME fd is %ld.\n",
      |                                                 ~~^
      |                                                   |
      |                                                   long int
      |                                                 %d
 1515 |            mapping->buffer_info.handle);
      |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~             
      |                                |
      |                                uintptr_t {aka unsigned int}
cc1: some warnings being treated as errors
make: *** [src/ffbuild/common.mak:81: libavutil/hwcontext_vaapi.o] Error 1

[Carl Eugen Hoyos]

You claimed that this ticket is Android-related and you forgot to tell us about the extra-cflags.
Please learn that there is no release support on this bug tracker, so nobody will look into your reports if you don't test current FFmpeg git head.
Does compilation really succeed with --disable-vaapi? The ticket seems to indicate this but I wonder if it is true...

[goffioul]

Please learn that the extra compilation flags were just a mean to an end, to reach a similar situation as when building within AOSP. The issue was detected with Android, but it's actually a generic incompatible pointer assignment problem, so I provided a simpler way for you to trigger the compilation error.

The variable buffer_handle is declared with type unsigned long. Its address is then assigned to a uintptr_t * field member. This trigger the Wincompatible-pointer-types warning in both gcc and clang, and a compilation error when using Werror.

To answer your question about using --disable-vaapi, obviously the original compilation error will disappear, as the corresponding file is not compiled in. It's a no-brainer. However, compilation still fails, but only with gcc, with this error:

src/libavutil/timecode.c: In function ‘av_timecode_make_string’:
src/libavutil/timecode.c:123:60: error: ‘%0*d’ directive output may be truncated writing between 1 and 10 bytes into a region of size between 2 and 14 [-Werror=format-truncation=]
  123 |     snprintf(buf, AV_TIMECODE_STR_SIZE, "%s%02d:%02d:%02d%c%0*d",
      |                                                            ^~~~
src/libavutil/timecode.c:123:41: note: directive argument in the range [0, 2147483647]
  123 |     snprintf(buf, AV_TIMECODE_STR_SIZE, "%s%02d:%02d:%02d%c%0*d",
      |                                         ^~~~~~~~~~~~~~~~~~~~~~~~
src/libavutil/timecode.c:123:5: note: ‘snprintf’ output between 11 and 32 bytes into a destination of size 23
  123 |     snprintf(buf, AV_TIMECODE_STR_SIZE, "%s%02d:%02d:%02d%c%0*d",
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  124 |              neg ? "-" : "",
      |              ~~~~~~~~~~~~~~~
  125 |              hh, mm, ss, drop ? ';' : ':', ff_len, ff);
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC	libavutil/tx.o
cc1: some warnings being treated as errors

This can be worked around by using --extra-cflags=-Wno-format-truncation, in which case ffmpeg compilation succeeds. This is however specific to gcc, as to my knowledge clang does not have Wformat-truncation warning. Hence, this specific error does not pop up with AOSP.

[Carl Eugen Hoyos]

If this is really the only error - as indicated by you - it is trivial to fix but as said this surprises me.

[goffioul]

I indicated initially 2 errors: one with Wincompatible-pointer-types in vaapi, and one with Wformat also in vaapi. This affects both gcc and clang.

Additionally, gcc also has an error in libavutil/timecode.c with Wformat-truncation (which is implicit when using Wformat).

If this is really the only error - as indicated by you - it is trivial to fix but as said this surprises me.

I'm not sure what you exactly mean by this, but if you mean that this is the only issue when compiling ffmpeg within AOSP, then the answer is no. There are a few warnings that need to be disabled, and I'm ok with that. But disabling Wincompatible-pointer-types does not seem a safe option to me; hence I reported it here.

[Carl Eugen Hoyos]

Type specifier fixed in 882a17068fd8e62c7d38c14e6fb160d7c9fc446a