[FFmpeg-devel] [PATCH] avcodec: Require avoptions for the user to set max_pixels.

[James Almer]

On 12/11/2016 10:29 PM, Michael Niedermayer wrote:
> On Sat, Dec 10, 2016 at 09:52:08PM -0300, James Almer wrote:
>> On 12/10/2016 9:23 PM, Michael Niedermayer wrote:
>>> On Sat, Dec 10, 2016 at 08:31:57PM -0300, James Almer wrote:
>>>> On 12/10/2016 7:01 PM, Michael Niedermayer wrote:
> [...]
> 
>>> And also theres more work for us to maintain seperate implementations
>>> for the options, all code accessing them has to deal with them being
>>> in different places, making all related backports harder.
>>>
>>> To me that looks like a disadvantage from every side
>>>
>>> I think the real solution is to start liking AVOptions, they make
>>> our work easier.
>>
>> AVOptions are fine. Private-but-not-really and no-direct-access fields
>> in public structs are what's kinda ugly an unpopular.
> 
> a slightly off topic question but
> if people care about these existing "no direct access" fields
> why do they not change them ?
> its a bit reading and thinking and droping the "no direct access"
> comments, this is not much work
> It requires a tiny bit of care so that future added fields dont do
> bad things and we should document that past releases still in some
> cases need the indirect access  ...
> 
> just seems a bit odd to me in relation to the opposition to add such
> a field were its needed for a bugfix but total apparent lack of
> interrest in removing such "no direct access" restrctions  where there
> is no reason at all to keep them

They are all supposed to stop being no direct access with the next bump.
Afaik most are remnants of the libav ABI compatibility days, same with
the get/setter functions, but they can't just be removed right now because
there are several versions using the current ABI (3.0 and newer i think).

Once that's done, any new field, be it ours or merged from libav, will
always go either at the end or below the "Internal from here on" marker,
assuming we don't get rid of those as well.