El viernes, 2 de febrero de 2018 11:05:36 -03 James Cowgill escribió:
> > 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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to