On 01/17/2013 11:28 AM, Ronald S. Bultje wrote: > Hi, > > On Thu, Jan 17, 2013 at 2:15 AM, Reinhard Tartler <siret...@gmail.com> wrote: >> On Thu, Jan 17, 2013 at 11:11 AM, Martin Storsjö <mar...@martin.st> wrote: >>> On Thu, 17 Jan 2013, Reinhard Tartler wrote: >>> >>>> On Wed, Jan 16, 2013 at 7:08 PM, Ronald S. Bultje <rsbul...@gmail.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Jan 16, 2013 10:01 AM, "Justin Ruggles" <justin.rugg...@gmail.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> On 01/16/2013 12:46 PM, Ronald S. Bultje wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Jan 16, 2013 9:43 AM, "Luca Barbato" <lu_z...@gentoo.org >>>>>>> <mailto:lu_z...@gentoo.org>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 16/01/13 11:46, Luca Barbato wrote: >>>>>>>>> >>>>>>>>> From: "Ronald S. Bultje" <rsbul...@gmail.com >>>>>>> >>>>>>> <mailto:rsbul...@gmail.com>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Signed-off-by: Luca Barbato <lu_z...@gentoo.org >>>>>>> >>>>>>> <mailto:lu_z...@gentoo.org>> >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Rebased and compile-tested on arm and powerpc. >>>>>>>>> >>>>>>>> >>>>>>>> Will be pushed in a while if nobody is against it. >>>>>>> >>>>>>> >>>>>>> I had a question for Justin: the prefix is avpriv_, so is order in >>>>>>> context part of abi? What about size? >>>>>> >>>>>> >>>>>> I'm not completely sure. The header is not installed so it's not public, >>>>>> so the only question I think is with mixing non-matching library >>>>>> versions. >>>>> >>>>> >>>> >>>> avpriv matches av* and thus is part of the exported symbols. >>>> Therefore, adding such a symbol warrants bumping minor (not major). >>>> please do that before pushing. >>>> >>>> mixing non-matching library version becomes interesting when you bump >>>> major. However, since all those symbols get proper symbol versions >>>> attached nowadays, this is no problem either. >>> >>> >>> It's not all that simple - the point here is that they're adding new fields >>> in a private struct (which is used in the implicit private ABI between lavu >>> and the others in this case) inbetween existing members. This means that an >>> old lavc that tries to use members from the floatdsp context in a newer lavu >>> will end up getting the wrong members. >> >> In that case, that's not private ABI. In fact, that term seems very >> wrong, either it something is part for the exposed interface or it is >> not. The difference here is that we do not expect applications and >> applications outside of libav to inteface them. Which may be fine, but >> hardly an excuse to sloppy on binary compatibility. If it breaks ABI, >> and there is no way around it, we need to bump major. >> >>> If the members are added at the end, there shouldn't be too much of an issue >>> though. >> >> If that works, then that's clearly preferable to bumping major! > > It changes size of the struct, thus embedding the struct in another > struct (in another lib) will break when mixing library versions. To > fix this, I believe we need a avpriv_alloc_floatdsp_context() function > (or something else that is able to calculate the size of > avfloatdspcontext at runtime, within libavutil).
That's pretty much what I was thinking as well. We could even change the init function to take AVFloatDSPContext ** and either allocate/init or just re-init if already allocated. -Justin _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
