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

Ronald S. Bultje rsbultje
Sun Feb 6 04:05:26 CET 2011


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.

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.)

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.)

Ronald



More information about the ffmpeg-devel mailing list