On Mon, Dec 12, 2016 at 09:48:01AM +0100, wm4 wrote: > 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?
If someone first checks that they are in the same offset in their structs in all FFmpeg releases with the same soname. And someone checks that we have no "insert new ... field above/below this line" things above them Yes, definitly [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
