[FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads
michael at niedermayer.cc
Mon Jan 25 19:50:53 CET 2016
On Mon, Jan 25, 2016 at 04:39:49PM +0100, Hendrik Leppkes wrote:
> On Mon, Jan 25, 2016 at 1:28 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> > Hi,
> > On Mon, Jan 25, 2016 at 4:01 AM, wm4 <nfxjfg at googlemail.com> wrote:
> >> On Sun, 24 Jan 2016 20:03:01 -0500
> >> "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> >> > Hi,
> >> >
> >> > On Sun, Jan 24, 2016 at 6:49 PM, Hendrik Leppkes <h.leppkes at gmail.com>
> >> > wrote:
> >> > > Unfortunately that doesn't alleviate the other issues, like the
> >> > > complexity needed in the decoders during frame threading, or the extra
> >> > > resources needed (extra image surfaces for every thread).
> >> > >
> >> >
> >> > So, the extra code is just in the decoders, which already need it anyway
> >> > (because they implement frame-mt), right? Or do hwaccels need extra code
> >> > also?
> >> >
> >> > The extra resources aren't a big deal IMO. Memory use isn't typically a
> >> big
> >> > issue, we're adding a fw kb extra for contexts but practically all memory
> >> > is in framebuffers regardless.
> >> It's can be a big deal for hardware decoding, because hw surfaces
> >> might be a more constrained resource than system RAM. Also, you often
> >> have to preallocate _all_ surfaces you're going to use, so you'll have
> >> to add the exact number of additionally needed surfaces to the
> >> preallocation.
> > If only one thread is active, the rest never has to be inited and thus
> > contains no surfaces (or framebuffers, or anything), right? If not, that
> > should be a trivial win.
> If you can implement it like this, ie. only make one single thread do
> the work, that would also avoid a bunch of the complexity with copying
> contexts around and avoiding multiple init calls of the hwaccel.
> On top of that, avoid the extra resource requirements and the delay
> inherent to frame threading otherwise, since no extra frames are
> "cached" inside the other worker threads.
is there no hwaccel that (can) work(s) with MT ?
iam bringing that up here before code is unconditionally removed that
might be needed for such case
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel