[FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads

[Andreas Cadhalpun]

On 21.01.2016 02:10, Hendrik Leppkes wrote:
> On Thu, Jan 21, 2016 at 1:14 AM, Andreas Cadhalpun
>> I'm still not sure of the scope that this problem has.
>>
>> If image corruption always happens with MT+HWAccel, why didn't VLC
>> change this long ago due to users complaining about that?
> 
> I don't know VLC internals, nor do I really use it beyond the occasional test.
> All I know is that back in 2014 they disabled MT with DXVA2 on their
> end because of just such corruption issues, but they worked around
> that somehow and turned it back on later.
> 
> http://git.videolan.org/?p=vlc.git;a=commitdiff;h=bf9b995528941436fbdfad6e60ce7af76f20ea2e
> 
> Looks like they added extensive locking around everything to prevent
> this, which is not something that should be required.

OK, it shouldn't be required and it isn't like the alternative solutions
found by other API users show.
However, it seems to work well enough, so I don't see the point in
breaking existing users like VLC by returning an error.
Though, when writing from scratch, it would be better to avoid the need
for extensive locking by using only one thread for hwaccel and if that fails,
reopening the decoder with more. Hence a warning would be fine.

>> Also, can the crashes be reproduced with the command line tools
>> from FFmpeg 2.8?
> 
> Yes, under some circumstances with DXVA2, but it needs some fancy
> files with resolution changes iirc.
> No, don't have a reproducable test case handy right now.

If it's so difficult to reproduce any kind of problem caused by this
combination I'm not sure why you insist on erroring out.

Also you only mention DXVA2 now, but the error is also returned for
VDPAU and VA-API. Are they also affected by these potential problems?

All in all it seems to me that the collateral damage caused by returning
the error outweighs it's value.

Best regards,
Andreas