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
0001-vp9-only-call-ff_get_format-on-stream-format-changes.patch
Description: Binary data
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
