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. This patch still disables hwaccel instead of disabling threading. This isn't gonna work. Please wait until my patch is finished. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
