Anton Khirnov (12021-12-12): > So what are you proposing? In my view, such higher level information > should live at a higher level - e.g. in the side data. You can then > have a filter that reads this side data and gets you the group you want.
So, what is the point of this new API if anything of value needs to be done with side data and yet another API? It seems to me you are indulging in a sunken-costs fallacy: you wrote this API and all the code but you neglected to poll your fellow developers for needs that it should cover, and as a result got something much too limited. But now, you are trying to force it anyway. What I propose is: (1) define the needs properly; (2) redesign the API; (3) see how much code can still be used. The needs as far as I can see, please add to the list: A. Allow the same channel to appear several time in the layout. Hendrik agreed that it was useful for some kind of USER_SPECIFIED or UNKNOWN channel specification, but allowing for any channel specification is actually simpler. It is not limited to just having the same channel in the list, it requires API and user interface support: the API must be able to tell the user "this USER_SPECIFIED channel is the oboe, this USER_SPECIFIED is the piano", and the user must be able to tell the API "the second USER_SPECIFIED channel" or "the USER_SPECIFIED channel relating to the piano". B. Possibly, I do not personally insist on it like A: groups of channels. -- 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".
