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

Nicolas George nicolas.george at normalesup.org
Sun Mar 17 14:47:20 CET 2013

Le sextidi 26 ventôse, an CCXXI, Michael Niedermayer a écrit :
> 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)?


  Nicolas George
-------------- 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/af8e1415/attachment.asc>

More information about the ffmpeg-devel mailing list