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

Michael Niedermayer michael at niedermayer.cc
Wed Aug 31 13:48:32 EEST 2016

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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160831/a887828b/attachment.sig>

More information about the ffmpeg-devel mailing list