On Tue, Jan 19, 2016 at 11:54 PM, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > On 19.01.2016 21:46, wm4 wrote: >> On Tue, 19 Jan 2016 21:31:19 +0100 >> Hendrik Leppkes <h.lepp...@gmail.com> wrote: >>> On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun >>> <andreas.cadhal...@googlemail.com> wrote: >>>> On 19.01.2016 21:22, Hendrik Leppkes wrote: >>>>> On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun >>>>> <andreas.cadhal...@googlemail.com> wrote: >>>>> They don't lack time, they lack understanding of the flaws in the system. >>>> >>>> How can you know that? >>> >>> Because I read the ticket, which says he doesn't want to do it, not >>> that he doesn't have time to do it, and because I know that particular >>> person and his attitude. >> >> It was discussed to death on #libav-devel too. > > And the conclusion was to allow hwaccel with frame threads? > >>> Its fundamentally broken, and making it a warning would re-introduce >>> known crashes. So no. >> >> +1 > > Can the crashes be reproduced with VLC? > If so, are they reported in the VLC bug tracker?
Who knows, I didn't test every single player that uses avcodec. The image corruption on Intel GPUs can certainly be reproduced in any player that uses MT+HWAccel though, so the crashes probably can too, but due to threading the crash is non-deterministic. > >> There was this idea that this could be fixed by having some sort of >> wrapper decoder, which could take care of the fallback transparently >> and without getting into these nasty threading issues. But no idea how >> much work that would be. > > Can't the framework just ignore the threading setting when using a hwaccel? > No, it starts up threads first before it knows a hwaccel is being used, and its not flexible enough to go in and out of threading mode at runtime. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
