[FFmpeg-devel] Evolution of lavfi's design and API

Paul B Mahol onemda at gmail.com
Wed Aug 31 15:20:27 EEST 2016

On 8/31/16, Michael Niedermayer <michael at niedermayer.cc> wrote:
> On Wed, Aug 31, 2016 at 10:18:31AM +0200, Paul B Mahol wrote:
>> On 8/30/16, Nicolas George <george at nsup.org> wrote:
>> > Le quartidi 14 fructidor, an CCXXIV, Paul B Mahol a ecrit :
>> >> the filter frame multithreading would just internally, in filter
>> >> context
>> >> cache frames, once enough frames are in cache - call workers and be
>> >> done,
>> >> repeat. At eof call workers on remaining frames in cache.
>> >
>> > I have no idea how much thought you have already given to it, but I am
>> > pretty sure it is not as simple as that with the current architecture.
>> > By
>> > far.
>> Yes, it is very simple. You just need to allocate own buffers that
>> would be needed
>> by filter. Than you just call ctx->internal->execute()...
> I would have thought that
> filter_frame() would insert frames into a input fifo and remove &
> output frames from a output fifo and pass them on to the next filters
> ff_filter_frame()
> if the output fifo is empty and the input full it would block
> (implicitly gving its CPU time to the workers)
> and there would be backgound threads continuosly running that pick
> frames out of the input fifo and process them into an output fifo
> and wake up the main thread if the fifo state changes
> using execute() would IIUC (please correct me if i misunderstand)
> only execute when ff_filter_frame() is executed, this would restrict
> what can execute at the same time, also execute() needs to
> wait for all threads to finish before it can return, this too limits
> paralelism compared to continuously running workers that more
> independantly pick tasks and work on them
> but maybe i misuderstood how you intend to use execute()

How this one would work if for example first frame needs 10 seconds to
generate and all other needs 1 second? How would you know from your output
fifo that you got first frame, so you can pass first frame to next filter(s)?

How do you know that your solution is always optimal? (Not saying that
mine is anything better)
How do you limit number of threads that will specifically work for
this filter instance?

More information about the ffmpeg-devel mailing list