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. I can see why having multiple channels with the same ID can happen, an in fact, will, for custom user layouts with more channels than there are IDs. For example, an Opus stream containing a hundred or so channels from multiple overlapping locations from a venue. Each of those channels would have to have an ID of NONE, because the codec mapping family doesn't carry such information for such a configuration. _______________________________________________ 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".
