[FFmpeg-devel] [PATCH] array AVOptions and side data preference
Anton Khirnov
anton at khirnov.net
Fri Feb 23 15:58:22 EET 2024
Hi,
this patchset implements a solution to the problem of side data
precedence for lavc decoding, recently raised by Derek (#10857).
The issue was caused by the recent addition of a mechanism for providing
global side data (typically from the demuxer) to decoders, which will
then propagate it to decoded frames. The problem is that some side data
may be present both in global headers and in the coded bytestream, which
will result in output frames having both attached, with no way to tell
which is which.
The solution in this set is as follows:
* at most one side data of a given type will ever be attached to a
frame
* by default, bytestream side data is preferred
* a new decoder option is added to allow overriding this default on a
per-side-data-type basis; to implement this I am adding array-type
AVOptions, which should also be useful elsewhere
Some potential points of interest:
* I am adding AVOption.array_max_size to allow specifying a maximum
array size for array-type options. Since Andreas seemed strongly
opposed to increasing sizeof(AVOption), I am placing it in a hole
before AVOption.unit (which is the reason 15/38 needs to go in as a
part of the major bump). This means that I cannot also add a minimum
array size. We might also:
* give up on specifying minimum size
* drop array size limits entirely (array_max_size is not used as of
this set)
* make array_max_size 16-bit and add a 16-bit min as well, since I
don't expect array sizes to be very large
* I am not providing any API for accessing array-type AVOptions other
than av_opt_{get,set}() (i.e. converting to/from strings), because
it's not strictly necessary for this set and I did not want to delay
the bump because of it. But clearly some such API will be needed.
Big thanks to Niklas for helping with decoder conversion.
Cheers,
--
Anton Khirnov
More information about the ffmpeg-devel
mailing list