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

[wm4]

On Mon, 12 Dec 2016 03:34:27 +0100
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Sun, Dec 11, 2016 at 10:51:08PM -0300, James Almer wrote:
> > 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).  
> 
> theres no need to wait for the next bump with removing many of the
> "no direct access" rules because the fields always where in the same
> position in the current major version
> 
> Removing them before the bump would allow people to stop using
> the accessors earlier
> 
> someone needs to read through the struct and think about it though
> so nothing is missed but from just the diff between master and
> the releases there seem to be many that did not move

Can I send a patch that makes them "real" public fields, and which
deprecates the accessors? In all libs?