On 2/1/20, Nicolas George <geo...@nsup.org> wrote: > Anton Khirnov (12020-01-28): >> That makes no sense. The filter cannot "have needs" when the current API >> does not support the use case you have in mind (which is good). The >> filter can either be modified to allow multiple inputs or a new filter >> can be added. > > It makes perfect sense: I know what I planned when I wrote them, and the > plan was always that when we would replace the channel layout API, it > would be able to express duplicated channels. And we will not demand > users to learn new filters for that. > > You can continue to disregard my arguments, and getting close to being > insulting while you are at it, but you will not get me to change my mind > like that. The API, as it is, is rejected. Either we design a good API, > one that can satisfy the needs you see and the needs I see, or we keep > the current, very simple, API. No half-measure that brings all the > drawbacks and almost no benefit.
Why you think you are not insulting other developers by your way of expressing your side of view. Very short sighted reasoning. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
