Hi, On Sat, Jan 23, 2016 at 8:28 AM, wm4 <nfx...@googlemail.com> wrote:
> On Sat, 23 Jan 2016 13:50:32 +0100 > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > On Sat, Jan 23, 2016 at 11:42:54AM +0100, Hendrik Leppkes wrote: > > > On Sat, Jan 23, 2016 at 10:12 AM, Andreas Cadhalpun > > > <andreas.cadhal...@googlemail.com> wrote: > > > > VLC uses hwaccel with frame threads and it works fine, but returning > > > > an error here made it fail. > > > > > > > > This regression was introduced in commit 31741ae. > > > > > > > > > > I'm still opposed to this, and so is everyone else that commented on > the issue. > > > > I have no oppinion on the patch itself but i think > > if MT+HWaccel works in some case(s) and is faster then there should be > > a way to enable that. We have optional "fast" decoding support too > > that skips some checks and could crash or uses simpler dequantization > > or our skip loopfilter support, ... > > Whether it's faster is an entirely different question. > > The problem is that we don't want to enable hwaccel with MT because > it's much pain for little gain, but then if fallback to software > happens, decoding will remain single-threaded. > > Possible solutions: > - somehow allow changing the number of frame threading threads during > fallback > - add a wrapper codec, which behaves like the old one, but reopens the > codec behind the scenes in order to change the number of threads on > fallback > - making sure hwaccels actually work with MT (complicated => not worth > the trouble) Why don't we ignore threading (set active_thread_type to NONE) if hwaccel is enabled? Doesn't that fix everything in one single place? Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
