On Mon, 05 Feb 2024 19:37:48 +0100 Niklas Haas <ffm...@haasn.xyz> wrote:
> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt
> <andreas.rheinha...@outlook.com> wrote:
> > This presumes the relevant states to be a cartesian product. Which need
> > not be true. A callback would be better; this would also allow to base
> > the list on other values already set in an AVCodecContext. And if this
> > were extended, it would also allow to remove init_static_data one day.
> > It is furthermore quite wasteful to store color_ranges in a list,
> > although there are only very few states for it.
>
> What signature would you propose for such a callback?
Well, there are two fundamental approaches here:
1. The callback somehow sets or returns a list of supported colorspaces.
2. The callback accepts a particular configuration and simply returns if
it's supported or not, with fields set to AVCOL_*_UNKNOWN being
ignored.
The first case has the pro of simplicity, and the ability to enumerate
more easily, but the drawback of only being scalable if we return
a cartesian set (i.e. set each attribute list independently, rather than
generating one big list).
The second case has the pro of flexibility, and the ability to handle
non-cartesian use cases, but the con of being slightly more awkward to
recover a list (for e.g. filtering purpose). Fortunately, we can recover
the minimal cartesian superset of the actual supported set in O(n) time,
and then still verify the exact format chosen at encode time.
One possibility could be to add a `test()` callback which simply tests
if the current codec context has valid parameters. For example:
struct AVCodecContext {
...
int (*test)(const AVCodecContext *ctx);
}
But this suggests a very stateful API, where you have to mutate
AVCodecContext in order to query what formats would be supported.
I don't like this.
So probably it makes more sense to just directly ingest a new struct
for this purpose, which we can then extend easily. (Or should we just
ingest AVFrame directly, i.e. int (*test_avframe)(ctx, AVFrame *frame)?)
_______________________________________________
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".
