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.cadhal...@googlemail.com> wrote: > > > > > On 25.01.2016 00:53, Hendrik Leppkes wrote: > > > > On Sat, Jan 23, 2016 at 3:52 PM, Andreas Cadhalpun > > > > <andreas.cadhal...@googlemail.com> wrote: > > > >> On 23.01.2016 15:10, Hendrik Leppkes wrote: > > > >>> On Sat, Jan 23, 2016 at 2:45 PM, Ronald S. Bultje <rsbul...@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" <rsbul...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
