[FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
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
More information about the ffmpeg-devel