Quoting Nicolas George (2021-12-09 14:52:40) > Anton Khirnov (12021-12-09): > > I fail to see how that is an advantage. You can just as well create > > multiple instances of those single-stream filters instead of adding > > hacks into core APIs. > > Please think a little further: multiple instances of the single-stream > filters would not have access to all the channels. > > > "possibly" is not a strong enough argument. I'd like to hear at least > > one clearly-defined use case that cannot just as well be handled by > > using multiple streams. > > This was a discussion for when the device was implemented. Now, it works > that way, the new API has to accommodate it. > > Anyway, these are just two example. I am sure we could find other > examples easily if we tried. It would be pretty stupid of us to add a > new API that is barely better than the current one and that we know is > too limited for likely use cases.
I see you repeating the same two arguments: - it was implemented like this in the past and therefore must keep working exactly the same - it might be useful under some vaguely specified conditions Neither of these strikes me as a good enough reason to make major changes to the API design. So again - can you describe a clearly-defined use case that cannot just as well be handled by using multiple streams? Empasis on "clearly defined", so not "I am sure we can find examples". I would like to hear some of those examples. So far you have not provided any. -- Anton Khirnov _______________________________________________ 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".
