On Tue, Feb 18, 2014 at 12:09 PM, Derek Buitenhuis < [email protected]> wrote:
> On 2/18/2014 6:00 PM, Steve Borho wrote: > > 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. > > If it really is this, then the API was documented wrong, and it does > some weird things. > It was documented wrongly; I've fixed that in recent commits. e.g. x265_picture_init() copies it over into the x265_picture.bitDepth > field, > which sure does look like *input* depth... > It is the default input depth. The user is responsible for making pic.bitDepth match the actual bit depth of the pixels they are passing in, if it doesn't match the internal depth. I tried to make that clear in the documentation for pic.bitDepth > > Let's keep this polite. I'll err on the side of bumping the build > number in the future. > > I may be somewhat grumpy due to coming back with my inbox full of people > blaming me. > Point them at me; it was definitely my fault. So when I bump X265_BUILD, ffmpeg will no longer try to compile against x265 until it is patched? How does this work in practice? Should I be sending patches for ffmpeg/libav when we change API? -- Steve Borho
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
