Quoting Lynne (2021-12-09 15:42:42) > 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.
That is pretty much already the case. I know there are files in the wild that have duplicated channels and the proposed API supports exporting this information. What I do _not_ want is treating such streams as first-class citizens that have to be fully supported by everything. They are a pathology and should be treated as such -- that is supported on input, but not output. > > 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. NONE is intended to be an invalid value, but we can add AV_CHAN_UNKNOWN with a high id for such a case. Or we can reserve a range of ids for application-specific usage. -- 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".
