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

[Michael Niedermayer]

On Thu, Feb 11, 2016 at 11:59:31PM +0100, Michael Niedermayer wrote:
> 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.

applied after IRC approval by author

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20160213/07c3ab3e/attachment.sig>