[FFmpeg-devel] [PATCH 2/6] Frame-based multithreading framework using pthreads
Sun Feb 6 10:02:05 CET 2011
On Feb 5, 2011, at 10:05 PM, Ronald S. Bultje wrote:
> 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.
>> + */
> 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.
More information about the ffmpeg-devel