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_*
>>   have been renamed to AV_INPUT_BUFFER_PADDING_SIZE and
>> - 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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to