On 20.01.2016 10:11, wm4 wrote: > On Tue, 19 Jan 2016 23:54:48 +0100 > Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: >> On 19.01.2016 21:46, wm4 wrote: >>> It was discussed to death on #libav-devel too. >> >> And the conclusion was to allow hwaccel with frame threads? > > From what I remember, the VLC developer in question showed no > interest in suggesting a proper solution.
:-/ >>> There was this idea that this could be fixed by having some sort of >>> wrapper decoder, which could take care of the fallback transparently >>> and without getting into these nasty threading issues. But no idea how >>> much work that would be. >> >> Can't the framework just ignore the threading setting when using a hwaccel? > > The problem is software fallback. If you run decoding with hwaccel and > 1 thread, and then fallback to software decoding, you can't just > increase the number of threads of the open context. Thanks for explaining. > This is why other hwaccel users simply recreate the decoder context > (and it works great). VLC could perhaps easily change their code to do > this. I thought so, too, until a VLC developer claimed it wouldn't be easy. > I'm quite surprised the developer seems to prefer to play such > games, instead of at least suggesting a solution or even just asking > the ffmpeg project for a revert. That was a surprise for me as well, and not a pleasant one. > I think it was mentioned that some newer hwaccels (VP9?) make it even > harder to somehow keep multithreaded hwaccels working, which is why > running with threading was disabled now. Hendrik can provide a better > explanation. OK. But I think this has worked more or less well in the past, so adding this error message and thus breaking this use is somewhat an API change. As such a deprecation period seems appropriate. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
