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) > Of course loosing videolan is a major problem too, i dont think > that should be taken lightly. It's just one of the developers acting up. > I dont understand the technical side of the MT+HWaccel problems well > enough to argue about that or possible solutions. > > [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
