Anton Khirnov (12020-01-07): > This API is the simplest way I could think of that achieves the desired > goals (bundling the channel count+layout together, allowing arbitrary > channel counts, ambisonic,...). Most things doable with the current API > are just as simple in the new one.
What I am saying is that the goals were not far enough. > Reference counting means dynamic allocation and a whole bunch of extra > complixity. I believe it is not worth it. This new API is not worth it if it does not allow a proper user interface for naming channels including when they are duplicated. > And the caller gets an extra opportunity to receive an invalid truncated > result if he doesn't go out of his way to check the result. If they chose so, it is their problem. But let us discuss that part in the other thread. > What questions about a channel layout would you consider relevant then? > > A channel layout IS - by definition - a mapping from stream indices to > semantics. 'What semantics does the n-th channel have' is one of just > two fundamental questions you can ask about a layout (the other one is > 'how many channels are there'), everything else is fluff. Ok. > Why would such filters exist and why would we accept them? I do not see > how can there be a clean user interface for a broken and undefined use > case. They are already there, they work very well, and people use them. Their behavior is perfectly well defined, but to give them a good user interface requires channel names and duplication. It's too bad you invested a lot of work while forgetting about them. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
