Hi, On Sat, Jan 23, 2016 at 8:51 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote:
> Hi, > > On Sat, Jan 23, 2016 at 8:45 AM, Hendrik Leppkes <h.lepp...@gmail.com> > wrote: > >> On Sat, Jan 23, 2016 at 2:38 PM, Ronald S. Bultje <rsbul...@gmail.com> >> wrote: >> > 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? >> > >> >> 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'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). Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
