On 2 May 2014 11:14, Luca Barbato <[email protected]> wrote: > On 02/05/14 19:57, Josh Allmann wrote: >> On 2 May 2014 10:16, Hendrik Leppkes <[email protected]> wrote: >>> On Fri, May 2, 2014 at 5:54 PM, Josh Allmann <[email protected]> >>> wrote: >>>> Since the scaler is often auto-inserted in video filtergraphs, >>>> this avoids a runtime error when filters are selectively enabled. >>> >>> I dunno, just because its commonly used at runtime shouldn't mandate >>> including it all the time. >>> If a user selectively disables it, its their own fault, isn't it. Its >>> default on afterall. >>> >> >> In that case, then why include fifos, buffers, ... ? >> >> If the scale filter is not unconditionally included, then it should >> not be auto-inserted. The user should not have to be aware of lavfi's >> plumbing -- that's the job of the build system. > > The problem is _quite_ annoying, if we do as you suggest we'd have > people screaming at us because they do not want swscale and their use > case is spoiled by the additional memory it requires for nothing. > > If we do not we'll have people complaining about having an unexpected > behaviour that forces them to rebuild the whole thing and add another. >
If pulling in libswscale is undesirable, then the scale filter should not be auto-inserted. Auto-inserted scale filters don't even work that well anyway. For example, in the overlay filter, it is only used for colorspace conversion -- the user still has to manually resize the overlay if the dimensions are incorrect, which adds another pass to the processing. What's more, unless the user sets a high debug level, he's probably not even going to realize another conversion is being done within lavfi (I didn't...). Principle of least astonishment: violated. This desire for granular control is really at odds with the automagic nature of filter auto-insertion. Josh > We have _suggest to declare this kind of dependency but I'm not sure it > would help in this specific case. > > Probably warning at the end of configure about suggested-but-disabled > filter isn't enough =\ > > lu > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
