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

[Michael Niedermayer]

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


> 
> 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.
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161212/da16bcac/attachment.sig>