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

Michael Niedermayer michael at niedermayer.cc
Thu Feb 11 23:59:31 CET 2016


On Mon, Feb 08, 2016 at 04:35:05PM -0500, Ronald S. Bultje wrote:
> 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

>  vp9.c |   60 +++++++++++++++++++++++++++++++++++-------------------------
>  1 file changed, 35 insertions(+), 25 deletions(-)
> 84b2a1d29ea965ee24ef82b0de63c0f6b91e9af6  0001-vp9-only-call-ff_get_format-on-stream-format-changes.patch
> From ec0a1e148d60a203a5bb82a8e9d7d3b97c5503dd Mon Sep 17 00:00:00 2001
> From: "Ronald S. Bultje" <rsbultje at gmail.com>
> Date: Mon, 8 Feb 2016 16:29:09 -0500
> Subject: [PATCH] vp9: only call ff_get_format on stream format changes.
> 
> In practice, this means we don't call it N times for N-threaded decoding.

iam in favor of this patch
multiple calls to ff_get_format() has lead to complaints in the past
from developers of multiple applications IIRC

Also we should get some solution
into git for FFmpeg 3.0 for the hwaccel-mt case.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160211/ca18de09/attachment.sig>


More information about the ffmpeg-devel mailing list