[FFmpeg-devel] [PATCH 000/279] New channel layout API

[Lynne]

9 Dec 2021, 15:57 by anton at khirnov.net:

> Quoting Lynne (2021-12-09 15:42:42)
>
>> 9 Dec 2021, 15:24 by george at 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.