On Mon, Jun 28, 2021 at 5:45 PM Gerd Röthig <dac324-at-yahoo...@ffmpeg.org> wrote: > > Hello all, > > Trying to compile the Chromium browser by myself, I encountered that compile > fails due to variable > declarations in ffmpeg_demuxer.cc in Chromium's source code. > > In the file, the following call to av_packet_get_side_data() is made: > > size_t id_size = 0; > uint8_t* id_data = av_packet_get_side_data( > packet.get(), AV_PKT_DATA_WEBVTT_IDENTIFIER, &id_size); > > size_t settings_size = 0; > uint8_t* settings_data = av_packet_get_side_data( > packet.get(), AV_PKT_DATA_WEBVTT_SETTINGS, &settings_size); > > Compilation fails, however, with the error "no matching function found for > av_packet_get_side_data", > and the reason appears to be the following code in libavcodec/packet.h, line > 626: > > uint8_t* av_packet_get_side_data(const AVPacket *pkt, enum > AVPacketSideDataType type, > #if FF_API_BUFFER_SIZE_T > int *size); > #else > size_t *size); > #endif > > If FF_API_BUFFER_SIZE_T is defined, this declaration expects *size to be of > type int instead of > size_t - because the size_t declaration sits in the #else branch of that > declaration (instead of the > #if branch as I (and apparently the Chromium developers) would have expected). > > But FF_API_BUFFER_SIZE_T, in my understanding, by its name should mean that > size_t is used, however, > the code in libavcodec/packet.h just handles it the other way round (ffmpeg > version n4.4). > > This means you can only have *size of type size_t when FF_API_BUFFER_SIZE_T > is NOT defined. > > Is this behavior intended? Or am I simply understanding something wrong here?
The define was not named the most clearly, but it behaves like a typical deprecation define - its automatically set based on the FFmpeg version, so that the new code automatically turns on during the next major bump. As such, the define being enabled would run the old code - eg. size as int, and the define being disabled would run the new code, size being size_t. These defines should never be set manually in any code, other then testing for an upcoming release by FFmpeg developers. For that matter, the depreciation period for that change has passed now and FFmpeg master now always uses size_t, perhaps this is where your conflict comes from. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
