El viernes, 2 de febrero de 2018 11:05:36 -03 James Cowgill escribió: [snip] > > 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. Oh, that's definitely a different story then. > > 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 Then yes, it's chromium's code. > > 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 know the feeling :-) > 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. Well, getting chromium fixed would be the first big step here. Then we can prod upstreams to use a new chromium version. -- Super cow powers | bbq > /dev/stomach Traveler1, seen on #debian-ar, irc.oftc.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
Attachment:
signature.asc
Description: This is a digitally signed message part.