[FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
Ronald S. Bultje
rsbultje at gmail.com
Sat Jan 23 14:38:41 CET 2016
On Sat, Jan 23, 2016 at 8:28 AM, wm4 <nfxjfg at googlemail.com> wrote:
> On Sat, 23 Jan 2016 13:50:32 +0100
> Michael Niedermayer <michael at 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.cadhalpun at 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
> - 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
> - 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?
More information about the ffmpeg-devel