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

[Alexander Strange]

On Feb 5, 2011, at 10:05 PM, Ronald S. Bultje wrote:

> Hi,
> 
> seems to work now, so time for smaller crap. Feel free to fix in a
> next submission or otherwise after commit is also fine.
> 
> On Sat, Feb 5, 2011 at 12:28 AM, Alexander Strange
> <astrange at ithinksw.com> wrote:
>> +        STATE_INPUT_READY,          ///< Set when the thread is awaiting a frame.
>> +        STATE_SETTING_UP,           ///< Set before the codec has called ff_thread_finish_setup().
>> +        STATE_GET_BUFFER,           /**
>> +                                     * Set when the codec calls get_buffer().
>> +                                     * State is returned to STATE_SETTING_UP afterwards.
>> +                                     */
> 
> /**< applies to previous element, /** to next, so use /**< here.
> 
>> +    int delaying;                  /**
>> +                                    * Set for the first N frames, where N is the number of threads.
>> +                                    * While it is set, ff_en/decode_frame_threaded won't return any results.
>> +                                    */
> 
> Same.

Fixed locally.

> 
> Slice-threads do nothing if n_threads <= 1, but frame-threads still
> allocates threads. Is that intended? Shouldn't it just be a nop if
> n_threads == 1? Or actually, since validate_thread_parameters() unsets
> active_thread_type, shouldn't this code be removed from thread_init()
> (the slice init one)? (Can be in a future commit.)

== 1 is turned into a nop in validate_thread_parameters().

> 
> Also, if you set n_threads to 1000 on a codec without threading
> support, it seems like it'll allocate 1000 slice-threads, which then
> do nothing? I know it did that before also. Should that be fixed, e.g.
> by introducing a CODEC_CAP_SLICE_THREADS? (In a future commit, not
> this one.)

Yeah, but is that a problem? 1000 is too many threads if the codec does support it.

I'd like to come back and make the slice threads only start when execute()/execute2() are called. Setting -threads in ffmpeg makes it start the same number of slice threads for the audio codec and encoders, when they don't always use them, and that clutters up debugger backtraces a little.