[FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads

[Ronald S. Bultje]

Hi,

On Tue, Jan 26, 2016 at 5:23 PM, Andreas Cadhalpun <
andreas.cadhalpun at googlemail.com> wrote:

> On 25.01.2016 00:53, Hendrik Leppkes wrote:
> > On Sat, Jan 23, 2016 at 3:52 PM, Andreas Cadhalpun
> > <andreas.cadhalpun at googlemail.com> wrote:
> >> On 23.01.2016 15:10, Hendrik Leppkes wrote:
> >>> On Sat, Jan 23, 2016 at 2:45 PM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> >>>> Both of you keep shouting from one side of the room to the other
> without
> >>>> trying to actually converge to a point that might somehow be mutually
> >>>> acceptable. I'm getting very grumbly here.
> >>>>
> >>>
> >>> I'm not trying to be unreasonable here, all I'm asking for at this
> >>> point is to make sure the new vp9 hwaccel doesn't break spectacularly
> >>> when MT is turned on before its allowed back.
> >>
> >> OK, that would be fine with me.
> >>
> >> Do you agree that the attached patch is sufficient for this?
> >>
> >
> > YUV420P will not remain the only format available for hwaccel, I
> > already have some work pending to allow Profile2/10-bit as well, so
> > the check should be further out.
>
> OK. Though if Ronald manages to (hopefully soon) find a solution for
> automatically throttling the hwaccel threads to 1, this check will be
> removed again anyway.
>
> > It would also log every time the function executes, no matter if
> > hwaccel is requested or not, unfortunately I don't see a way to fix
> > that nicely since the decoder doesn't know if the user is going to
> > activate hwaccel.
>
> Indeed. But since that is anyway logged in setup_hwaccel there
> is not really much need for another warning here. I've thus reduced
> the log level to verbose. Attached is an updated patch.


See attached for what I had in mind, and along with this you can then
remove the current blocking code in libavcodec/utils.c which you're
complaining about.

So, this _sometimes_ works for dxva2/vp9, but it still fails sometimes.
Hendrik thinks it's related to dxva2 generic buffer handling, not
vp9-related anymore, and in line with that, it's indeed true that
h264/dxva2 hwaccel+threading fails also. vdpau hwaccel+mt works, but has no
vp9 so we can't confirm if vp9 is fine here. I haven't found anyone with
vaapi vp9 yet...

Hendrik is not against applying this, but the question is whether it's
helpful, because if you remove the libavcodec/utils.c block, mt+hwaccel for
dxva2 will fail again (easily reproduced with make THREADS=4 HWACCEL=dxva2
fate-h264/vp9 -k). Hendrik suggested possibly putting locks around the
dxva2 picture pool, but that's stupid. Also, this whole setup still doesn't
allow much room for adaptive fallback and delayed hw decoding (i.e. having
multiple buffers in the hw queue), since the hw is disabled without flush
as soon as we switch between hw and fallback...

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-vp9-only-call-ff_get_format-on-stream-format-changes.patch
Type: application/octet-stream
Size: 4443 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160208/3f873e62/attachment.obj>