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

[Anton Khirnov]

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.

-- 
Anton Khirnov