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

[Michael Niedermayer]

On Wed, Aug 31, 2016 at 02:20:27PM +0200, Paul B Mahol wrote:
> 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)?

one possibility:

frame 1 comes in

first worker adds a output entry to the end of the output linked list
and  starts working on frame 1

frame 2 comes in

second worker adds a output entry to the end of the output linked list
and starts working on frame 2

second worker finishes and replaces/adds its output to its output entry

frame 3 comes in, the next output entry (from worker 1) is not finished
so nothing can be output yet

second worker adds a output entry to the end of the output linked list
and starts working on frame 3

first worker finishes and replaces/adds its output to its output entry

frame 4 comes in, the next output entry (from worker 1) is ready and
is sent to the next filter



> 
> How do you know that your solution is always optimal? (Not saying that
> mine is anything better)

i dont know if its always optimal, in fact it likely is not always
optimal. It seemed simple and reasonably good.


> How do you limit number of threads that will specifically work for
> this filter instance?

i had assumed that a fixed number of worker threads would be used
for each filter, some of these may be idle and consume no CPU if there
is nothing to do
I assumed a fixed number for simplicity, nothing in the design
should depend on the number being fixed


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
-------------- 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/20160901/260f6ac2/attachment.sig>