On Wed, Aug 31, 2016 at 02:20:27PM +0200, Paul B Mahol wrote: > On 8/31/16, Michael Niedermayer <mich...@niedermayer.cc> wrote: > > On Wed, Aug 31, 2016 at 10:18:31AM +0200, Paul B Mahol wrote: > >> On 8/30/16, Nicolas George <geo...@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"
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
