Anton Khirnov <[email protected]> writes: > On Mon, 02 Jan 2012 11:12:52 +0000, Måns Rullgård <[email protected]> wrote: >> Anton Khirnov <[email protected]> writes: >> >> > Based on code by Michael Niedermayer. >> > --- >> > avconv.c | 12 +------- >> > libavfilter/vsrc_buffer.c | 61 >> > +++++++++++++++++++++++++++++++++++++++++++++ >> > 2 files changed, 63 insertions(+), 10 deletions(-) >> >> This seems wrong. Resolution changes should be allowed if the immediate >> consumer supports it. If at some stage in the processing chain an >> element does not support resolution changes, any auto-scaling should >> happen there, not sooner, and certainly not bolted to the buffer source. >> >> An obvious example of where this is wrong is when there is already a >> scaler in the chain. On a change in input resolution, the proper action >> is then to reconfigure the existing scaler, not add another one. >> >> Furthermore, it could be argued that automatic insertion of scalers is >> evil in general if unless requested by the user. At the very least, the >> user should be offered some control over how it happens. >> > > I agree with this, but doing that will take some time. And currently > lavfi segfaults on resolution change, which is not a good thing to have > in the release.
Since it doesn't currently work at all, simply failing with a clean error message instead would not be a regression and would not make fixing it properly harder. > I think we should push this for 0.8 with a fixme and properly solve this > later. 1) Nothing lasts longer than a temporary hack. 2) This addition complicates the code, thus making a future proper solution more difficult. 3) Adding this now might introduce some behaviour that is difficult to preserve when it is done properly, which will annoy anyone who might have come to rely on it. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
