On Sat, Dec 24, 2016 at 06:41:32PM +0100, Nicolas George wrote: > This rather long patch series introduces a new way of designing filters. > > The series is rather long in number of patches, but each step is quite > simple and straightforward. > > The new design is this: instead of having filter_frame and request_frame > on all pads, filters have a single callback, activate, and examine the > links' FIFOs and status to decide what they need to do and do it. > > Note that a lot of filters already do it: filter_frame adds the frame to a > queue, request_frame detects EOF, and both call a common processing > function: the common processing function would become activate. > > A lot of helper functions are there to make this as lightweight as > possible. > > Each step passes FATE. >
> The API I intend for filter starts to be visible, therefore I would like > advice about how convenient and elegant people find it. after one quick pass looking through this i have mainly one request please seperate functions intended to be used by filters from functions intended to be used by the core. Maybe by using 2 seperate headers. As it is its connfusing and i on several cases am not sure in which category functions are intended to be in. People writing filters need to know which functions they can use and which they dont need to know of also i think if we have a header called internal it shouldnt (need to) be included by everyhing. While this is not at all specific to lavfi, it just feels semantically wrong everytime i see it thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel