Bug 40842

Было бы интересно узнать, где они взяли 57-ю версию libavutil.

Может я что-то упускаю. Вот моя проблема: В chromium используется size_t в качестве третьего аргумента av_packet_get_side_data. При использовании системной библиотеки получаю ошибку:

../../media/filters/ffmpeg_demuxer.cc:432:24: error: no matching function for call to 'av_packet_get_side_data'
    uint8_t* id_data = av_packet_get_side_data(
                       ^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/libavcodec/packet.h:626:10: note: candidate function not viable: no known conversion from 'size_t *' (aka 'unsigned long *') t
o 'int *' for 3rd argument

В /usr/include/libavcodec/packet.h декларация:

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

В /usr/include/libavutil/version.h написано:

#define LIBAVUTIL_VERSION_MAJOR 56
...
#ifndef FF_API_BUFFER_SIZE_T
#define FF_API_BUFFER_SIZE_T (LIBAVUTIL_VERSION_MAJOR < 57)
#endif

Я предположил, что раз такое условие включения FF_API_BUFFER_SIZE_T, то должно быть условие переводящее его в false. Выставлять -DFF_API_BUFFER_SIZE_T=0 приведёт к тому, что в место указательня на int хромиум будет передавать указатель на unsigned long, что не выглядит хорошей идеей.

Поэтому я и решил открыть эту багу. Возможно, ты мне что-нибудь подскажешь. Я вполне допускаю, что неправ chromium и нужно использовать их внутреннюю копию библиотеки.

Если в chromium используется size_t, то похоже, что они перешли на версию ffmpeg из ветки master.

Вот эти условия в декларациях, про которые ты пишешь были добавлены с таким changelog в изменениях:
2021-03-10 - xxxxxxxxxx - lavu 56.68.100 - buffer.h
  Change AVBufferRef related function and struct size parameter and fields
  type to size_t at next major bump.

major bump ещё не случился и у нас собрана самая последняя версия 4.4.

Ты можешь посмотреть, откуда они втащили себе ffmpeg ?

И да, возможно что собирать его с внутренним ffmpeg это хорошая идея, надо смотреть что они ещё в нём меняют.

(Ответ для Anton Farygin на комментарий #3)
> Если в chromium используется size_t, то похоже, что они перешли на версию
> ffmpeg из ветки master.
> 
> Вот эти условия в декларациях, про которые ты пишешь были добавлены с таким
> changelog в изменениях:
> 2021-03-10 - xxxxxxxxxx - lavu 56.68.100 - buffer.h
>   Change AVBufferRef related function and struct size parameter and fields
>   type to size_t at next major bump.
> 
> major bump ещё не случился и у нас собрана самая последняя версия 4.4.

Похоже на то.

> Ты можешь посмотреть, откуда они втащили себе ffmpeg ?

Name: ffmpeg
URL: http://ffmpeg.org/
License: LGPL 2.1
License File: CREDITS.chromium
Upstream Git: git://source.ffmpeg.org/ffmpeg.git
Last Upstream Merge: 8649f5dca6688feb66f787dcf232d42ed20fdb28, May 09 2021

Я долгое время использовал системную библиотеку поскольку у хромиума нет патчий на внутеннюю копию в отличии от остальных внутренних библиотек.

> И да, возможно что собирать его с внутренним ffmpeg это хорошая идея, надо
> смотреть что они ещё в нём меняют.

Это повлечёт свои поблемы, но похоже, что так.

Тогда багу можно закрывать.

выйдет новый major release - можно будет опять отключить.

(Ответ для Anton Farygin на комментарий #5)
> выйдет новый major release - можно будет опять отключить.

С таким апстримом я смысла не вижу. И так приходится кучу всего вычитывать, чтобы  собрать из "релиз".