[FFmpeg-devel] [PATCH] avcodec: only warn about hwaccel with frame threads

[Hendrik Leppkes]

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.

- Hendrik