[FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
h.leppkes at gmail.com
Wed Jan 20 10:22:43 CET 2016
On Tue, Jan 19, 2016 at 11:54 PM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 19.01.2016 21:46, wm4 wrote:
>> On Tue, 19 Jan 2016 21:31:19 +0100
>> Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>>> On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun
>>> <andreas.cadhalpun at googlemail.com> wrote:
>>>> On 19.01.2016 21:22, Hendrik Leppkes wrote:
>>>>> On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun
>>>>> <andreas.cadhalpun at 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.
> 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
More information about the ffmpeg-devel