On 12/10/2016 7:01 PM, Michael Niedermayer wrote: > When we will backport this, it will be inevitably in a different location > in AVCodecContext in each release and master. 3.0, 3.1, 3.2 and master > use the same soname though and must have a binary compatible interface. > It thus can only saftely be accessed through AVOptions > > It may be enough to require this only in the releases but that could be > rather confusing.
Wouldn't it be better to initially add such new fields inside AVCodecContext->internal and accessible by AVOptions only so they may be trivial to backport, then once a major bump occurs they can be moved to the actual public struct with enabled direct access? Not sure how feasible is to have options_table.h options change values from that internal struct, but it would solve the above concerns. > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> > --- > libavcodec/avcodec.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index 02234aee67..8123092ac0 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -3573,8 +3573,8 @@ typedef struct AVCodecContext { > /** > * The number of pixels per image to maximally accept. > * > - * - decoding: set by user > - * - encoding: set by user > + * - decoding: set by user through AVOptions (NO direct access) > + * - encoding: set by user through AVOptions (NO direct access) > */ > int64_t max_pixels; > > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel