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

wm4 nfxjfg at googlemail.com
Fri Jan 22 09:55:36 CET 2016

On Fri, 22 Jan 2016 00:14:15 +0100
Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:

> On 21.01.2016 23:56, Hendrik Leppkes wrote:
> > On Thu, Jan 21, 2016 at 8:36 PM, Andreas Cadhalpun
> > <andreas.cadhalpun at googlemail.com> wrote:  
> >> On 21.01.2016 02:10, Hendrik Leppkes wrote:  
> >>> Looks like they added extensive locking around everything to prevent
> >>> this, which is not something that should be required.  
> [...]
> >>> 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.  
> > 
> > Just because an error is rare, we should leave it in? What kind of bug
> > squishing concept is that?  
> No, you misunderstood me.
> The real problem happens rarely, but the error is always returned.
> So on one hand returning this error prevents rare problems, when the
> API is (mis)used, but on the other hand it breaks the use case of VLC,
> which, as you say, prevents the real problem by extensive locking.
> So returning this error breaks more than it fixes.
> >> 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?  
> > 
> > I would assume thread safety might be an issue for all of them. Our
> > VA-API maintainer signed off on the patch in any case.  
> So it seems to be a theoretical problem for them, but still the error
> is returned. That doesn't seem correct.
> >> All in all it seems to me that the collateral damage caused by returning
> >> the error outweighs it's value.  
> > 
> > I disagree, and apparently so did the others that OK'ed the patch.  
> When this patch got OK'ed at least I wasn't aware of it's implications.
> > On top of all that, not even the player in question seems to care,
> > otherwise we might have gotten at least one official comment or
> > question from them, but alas, silence.  
> I do care about this, however.

In any case, what was going on with hw decoding and frame threading
seemed pretty insane. So even if this is a "regression", the burden of
proof that it actually works is IMHO on the side of those who want to
reenable it.

More information about the ffmpeg-devel mailing list