[FFmpeg-devel] [PATCH 2/6] Frame-based multithreading framework using pthreads

[Ronald S. Bultje]

Hi,

On Sat, Feb 5, 2011 at 4:43 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Feb 05, 2011 at 04:20:38PM -0500, Ronald S. Bultje wrote:
>> On Sat, Feb 5, 2011 at 3:55 PM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> > My suggestions is to add a way to detect which types (or at least if at
>> > all) threading will be used, and to add that in a way that allows to
>> > still change the draw_slice, get_frame and possibly other callback pointers.
>> > It's not a big deal if we do not manage to get it 100% accurate in cases
>> > where it depends on content (e.g. for slice multithreading), but at least
>> > the big cases "codec does support MT" and "FFmpeg compiled without pthread"
>> > should be covered.
>>
>> I see, so something like AVCodec bla { [..] .capabilities = horiz_band
>> | bla | ONLY_IF_THRADS_ENABLED(CODEC_CAP_FRAME_THREADS) [..] would be
>> sufficient?
>>
>> (And I guess we'd need a similar flag for slice-threads also?)
>
> In principle I would prefer something more convenient to check and
> that e.g. could be set in decoder init based on extradata,
> but as a baseline I guess this could work "well enough" at least.

I suppose avcodec_thread_init() (called before avcodec_open()) could
set avctx->thread_count to 1 if both types of threads are not
available (if slice_threads thread_init() else if frame_threads
frame_thead_init() else avctx->thread_count = 1, that in combination
with the above not-setting-the-flag-if-no-pthreads-are-available would
do what you want, I think. Is that sufficient? Then again,
thread_count=1 still means 1 thread is created so maybe we should use
thread_count=0 for this, or create no threads if thread_count=1.

Ronald