On Mon, 12 Dec 2016 03:34:27 +0100 Michael Niedermayer <mich...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
