[FFmpeg-devel] [RFC] threading API
Reimar Döffinger
Reimar.Doeffinger
Tue Oct 6 09:01:15 CEST 2009
Hello,
as I pointed out it would be better and result in simpler code if e.g.
dnxhdenc produced one task per slice always.
As Baptiste pointed out this requires to allocate one whole context per
slice regardless of the number of threads, which seems a bit like
overkill.
Now ideally those threaded functions should be changed not to do any
changes to the context when they do not need to be persistent, but that
seems a lot of work, particularly as in the future some MPegEnc contexts
or whatever might become involved.
Also, having to create an int* array when we only need a slice number
seems a bit like overkill.
So I wanted to ask what you think about changing the functions argument
of execute (I just realize that is quite a problem since it is part of
the public API :-( ), from
int (*func)(struct AVCodecContext *c2, void *arg)
into
int (*func)(struct AVCodecContext *c2, void *arg, int workload, int thread)
Where "workload" is the "workload" number, i.e. the index used to
calculate arg, and thread is the number of the thread that does the
executing.
This would allow sharing the same context for things that are executed
by the same thread, reducing memory usage and cache pressure, for very
simple stuff that does not change any context stuff it simplifies the
code since it does not need to use the arg2 argument to ->execute but
instead can use the "workload" directly.
The later is only a very minor optimization, and if a API change should
be avoided by all means, the former can be achieved also by adding to
AVCodecContext a set_thread_number callback, that if set is executed
each time before the main worker function with the same void *arg, i.e.
void (*set_thread_number)(struct AVCodecContext *c, void *arg, int thread)
So, what are the opinions? Other ideas?
More information about the ffmpeg-devel
mailing list