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 <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 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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
