On Tue, Feb 18, 2014 at 9:46 AM, Derek Buitenhuis < [email protected]> wrote:
> So. > > > https://bitbucket.org/multicoreware/x265/commits/b1f5fd61883a0f375bbb5012fc41a5661c0b9389 > > This introduced an API change with NO version bump. > This was my fault; I was uncertain about the guarantees of the build number. It mainly seems to function as a link guard to prevent linking to a library with a different API. But this particular change did not actually change the API; that particular field had always been effectively the internal bit depth for the shared library. So ffmpeg would have been able to link to and use libraries built after this change, but it would not be able to compile against it. People complained stuff no longer builds. > > > https://bitbucket.org/multicoreware/x265/commits/ce96cdb390fe26aee6effa731e51303c1d9056b0 > > "Fixed" it in the worst possible way. > > It is not OK to re-purpose things like this, silently. It means code will > keep > compiling, but do the wrong thing. > I disagree; any program that used the old API can use the new one without any change because before that commit internal and input bit depth were always the same. Both before and after that commit that particular field has only served to validate that the user was aware of whether the library was compiled for 16bpp or not. > So please, bump the X265_BUILD number next time and no silently change > behavior in the background, which was previously correct. It's not > amateur hour. > Let's keep this polite. I'll err on the side of bumping the build number in the future. -- Steve Borho
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
