[FFmpeg-devel] lavfi: request_frame() return value.

[Michael Niedermayer]

On Sun, Mar 17, 2013 at 02:47:20PM +0100, Nicolas George wrote:
> Le sextidi 26 ventôse, an CCXXI, Michael Niedermayer a écrit :
> > IMHO:
> > the min/max handling should be moved to a seperate filter and this
> > filter should be auto inserted where needed/requested. This new filter
> > would have a request_frame that returns correct data/no data
> > information
> 
> My opinion in this matter is that auto-inserting filters is more fragile
> than doing the same work directly in the code. I can suggest an argument to
> justify that: inconsistent API changes are likely to cause build failures,
> and therefore are detected at build time, while problems caused by changes
> in a filter's arguments syntax will only be detected if the corresponding
> code is used. Of course, a FATE test would fix it too.
> 
> But for this reason I believe that core and utility features should go in
> the framework code, and that the graph should be left as much as possible as
> the user wrote it.

Code in individual filters is much easier to maintain and understand.

Consider this, a developer wants to do work on the min/max code, be
that a bugfix or feature or whatever
if its a seperate filter he has it all in a single (and small) file
which interfaces with the outside by the same API that all other
filters use.
If OTOH its in the core, even just finding all related code can take
some effort, understanding it so that developer can work on it also
is harder because theres no clear API that delimits it from other
parts. The developer here first needs to understand the internal
"interface" between the code he is interrested in and the rest of the
core he is not really interrested in but probably has to read and
understand too to some extend

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130317/d3b1a7b6/attachment.asc>