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() [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
