9 Dec 2021, 15:57 by an...@khirnov.net: > 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. >
I'm fine with this. I think an AV_CHAN_UNKNOWN ID is needed pretty much anyway, and as for user IDs, maybe a single AV_CHAN_CUSTOM or AV_CHAN_USER_DEFINED. The user could then use the channel opaque field to store some info, such as an index into their frame->opaque_ref data with which they could store channel-specific offset. So I'm fine with your proposal to have 16-bit enum for the channel ID and a 16-bit opaque. Though I'd like the opaque to be an uint16_t instead of int opaque : 16. And 16-bits does sound like enough for many channels and quite a few flags, though the silent flag should be moved to 1 << 15 instead of 64, and any new flags could be added beneath so as to not conflict with channels. _______________________________________________ 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".
