[FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads

[Michael Niedermayer]

On Sat, Jan 23, 2016 at 10:55:00AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Jan 23, 2016 at 8:51 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> 
> > Hi,
> >
> > On Sat, Jan 23, 2016 at 8:45 AM, Hendrik Leppkes <h.leppkes at gmail.com>
> > wrote:
> >
> >> On Sat, Jan 23, 2016 at 2:38 PM, Ronald S. Bultje <rsbultje at gmail.com>
> >> wrote:
> >> > Hi,
> >> >
> >> > 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
> >> >>   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?
> >> >
> >>
> >> Threading is already setup and running when the hwaccel gets
> >> activated, and its not designed to go in and out of threading mode at
> >> will.
> >
> >
> > Ok, so we can change how threading works. A fairly simple solution may be
> > to have a hwaccel flag that says whether it's threadsafe (whitelist style),
> > and if that's not set and hwaccel is enabled and active, have either
> > hwaccel or threading code "throttle" the number of iterating threads to 1
> > (i.e. you have N running threads, but N-1 idle and only 1 is ever accessed
> > while throttle-mode is active). This way, software fallback still works.

i was thinking the same yesterday but wasnt sure enough i understand
the problem well enough to suggest it


> >
> 
> I'd want to poke this again before it gets lost. I'd like software fallback
> with threading to work, and hwaccel to be used by default (w/o threading,
> if needed). This proposal still seems the only one that accomplishes that.
> Can I get votes on this? I can implement if I get access to systems with
> hardware support (or examples for local reproduction).

+1, iam happy about any solution

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160123/652eff02/attachment.sig>