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

[Clément Bœsch]

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.
> 
> I would appreciate the opinion of the other frequent developers of lavfi on
> that matter.
> 
> > this is actually orthogonal to your suggestions and can be implemented
> > with or without them
> 
> Indeed. Clément, Stefano, any advice on the best of the three options (leave
> as is; change the semantic of "return 0" and let the sinks do the work;
> handle looping in the framework)?
> 

I'd say 2 & 3 (if->while and auto-insert), because I like the idea of
being able to simplify the filters themselves (the request_frame callback
can make a very simple filter looks extremely messy), and the
auto-inserted segmentation filter is a more expressive way of showing
what's happening than having it in the core like now (where it's not easy
to get a clue what's going on).

Apart from this, I need a fix for min/max samples ASAP so I can unblock
the current work with metadata in filters :)

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130317/a763b7fa/attachment.asc>