On Thu, Dec 9, 2021 at 3:42 PM Lynne <d...@lynne.ee> wrote: > > 9 Dec 2021, 15:24 by geo...@nsup.org: > > > Anton Khirnov (12021-12-09): > > > >> 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. > >> > > > > I will turn this argument back on you: you have designed your API so > > that it is too limited, it does not strike me as a good reason to make > > major changes in existing filters and devices that have given > > satisfaction to users for years. > > > > As a compromise, could we specify that while having multple > channels with the same ID in a single frame can happen and > can be generated by decoders, we would also specify that they > possibly won't be treated correctly by encoders and filters, and > could be outright dropped with a warning if unsupported. >
Actually thats the worst part of it, and I would be happy to not have to think about that, as an API user. What kind of sense does a frame make that contains the same channel twice? What am I ever supposed to do with that? It sounds to me like some kind of theoretical design flaw is trying to be solved at the wrong point, instead of clearly separating streams, they are supposed to live together but somehow still be separate? That just sounds like a hack to me. Two streams are two streams, not one stream with somehow duplicated channels. - Hendrik _______________________________________________ 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".
