[FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
Ronald S. Bultje
rsbultje at gmail.com
Wed Jan 27 01:16:35 CET 2016
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>
> >>>> Both of you keep shouting from one side of the room to the other
> >>>> 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.
More information about the ffmpeg-devel