Новому chromium очень хочется работать с libavutil >= 57. Обновите пакет если можно. Очень не хочется использовать внутреннюю версию.
Было бы интересно узнать, где они взяли 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 - можно будет опять отключить. С таким апстримом я смысла не вижу. И так приходится кучу всего вычитывать, чтобы собрать из "релиз".
