Hi, On 02/02/18 13:50, Lisandro Damián Nicanor Pérez Meyer wrote: > El miércoles, 24 de enero de 2018 19:26:50 -03 jcowg...@debian.org escribió: >> Source: qtwebengine-opensource-src >> Version: 5.9.2+dfsg-2 >> Severity: important >> User: debian-multime...@lists.debian.org >> Usertags: ffmpeg-3.5-transition >> >> Hi, >> >> Your package FTBFS with the upcoming version 3.5 of FFmpeg. In FFmpeg 3.5, >> there are a number of API changes which will cause many packages to FTBFS. >> For this reason I have uploaded an early development snapshot to >> experimental before the 3.5 release in an attempt to fix some of these a >> bit quicker. While 3.5 has not been finalized and the ABI is not stable >> yet, there should not be any significant API breakages before the release. >> >> Incomplete list of changes (based on looking at common build failures): >> - Some fields in AVCodecContext have been removed and replaced with private >> options which can be set using the av_opt_set* APIs >> - Most CODEC_* constants have been renamed to AV_CODEC_* >> - The buffer constants FF_INPUT_BUFFER_PADDING_SIZE and FF_MIN_BUFFER_SIZE >> have been renamed to AV_INPUT_BUFFER_PADDING_SIZE and >> AV_INPUT_BUFFER_MIN_SIZE. >> - The old resampling API provided by libavcodec has been removed. Use >> libswresample instead. >> - The libavfilter/avfiltergraph.h header has been removed, include >> libavfilter/avfilter.h instead. >> - The AVFrac structure (representing mixed rational numbers) has been >> removed. > > Hi James! Qt upstreams will certainly not start developing against a new > FFmpeg version until it gets released.
Having FFmpeg 3.5 released is not a prerequisite to fix this. All the old APIs in FFmpeg 3.5 have been deprecated for 2 years (or much longer in some cases). The new APIs are already in old FFmpeg versions. > That means *at very least* 6 months of > delay from the day FFmpeg 3.5 gets released. > > As this bug is filed against qtwebengine *it might happen* that the web > engine > itself needs an update, in that case the engine must be updated first and > then > Qt will follow. I have not specifically looked at qtwebengine, but the build log indicates that the bugs are in the chromium code. Eg: > ../../3rdparty/chromium/media/filters/ffmpeg_audio_decoder.cc:56:35: error: > 'CODEC_CAP_DR1' was not declared in this scope > So I'm afraid it's either waiting or having more than one FFmpeg version in > the archive. I assure you there there will not be more than one FFmpeg version in the archive at once :) I already expect I will have to help patch a lot of these bugs (given the amount of work which past FFmpeg transitions have taken). I will try to look at this and the build failure in chromium once we get closer to when I would like to start the transition. Thanks, James
signature.asc
Description: OpenPGP digital signature
