[FFmpeg-devel] lavfi: introduce a new way of designing filters
michael at niedermayer.cc
Sun Dec 25 03:17:48 EET 2016
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
> 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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel