On Sun, Dec 11, 2016 at 3:59 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Sun, Dec 11, 2016 at 01:54:28PM +0100, wm4 wrote:
>> On Sat, 10 Dec 2016 23:01:04 +0100
>> Michael Niedermayer <mich...@niedermayer.cc> 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.
>> >
>> > 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;
>> >
>>
>> Why? We gave up the Libav ABI compat. abomination.
>
> Its explained in the patch comment above
>
> max_pixels should to be backported as it allows users to control memory
> use from large images better, avoid some OOMs and fixes issues which
> some people consider security bugs
> if its backported it will not be in the same location relative to the
> start of AVCodecContext in master, 3.2, 3.1, 3.0
> master, 3.2, 3.1, 3.0 all have the same soname
> libs using the same soname need to be binary compatible
> direct access to one location will not work and thus be binary
> incompatible if the field is at a different location
>
> Thus releases cannot use direct access to the max_pixels field.
> One could say it differently in that if 3.0.X would access max_pixels
> directly at byte offset 123 then an application built against that
> and linked to 3.2 will access another field before max_pixels in 3.2
>
Thats why one doesn't backport features. It just causes headaches when
structs change.
- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
