<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 9:46 AM, Derek Buitenhuis <span dir="ltr"><<a href="mailto:derek.buitenhuis@gmail.com" target="_blank">derek.buitenhuis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So.<br>
<br>
<a href="https://bitbucket.org/multicoreware/x265/commits/b1f5fd61883a0f375bbb5012fc41a5661c0b9389" target="_blank">https://bitbucket.org/multicoreware/x265/commits/b1f5fd61883a0f375bbb5012fc41a5661c0b9389</a><br>
<br>
This introduced an API change with NO version bump.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
People complained stuff no longer builds.<br>
<br>
<a href="https://bitbucket.org/multicoreware/x265/commits/ce96cdb390fe26aee6effa731e51303c1d9056b0" target="_blank">https://bitbucket.org/multicoreware/x265/commits/ce96cdb390fe26aee6effa731e51303c1d9056b0</a><br>
<br>
"Fixed" it in the worst possible way.<br>
<br>
It is not OK to re-purpose things like this, silently. It means code will keep<br>
compiling, but do the wrong thing.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So please, bump the X265_BUILD number next time and no silently change<br>
behavior in the background, which was previously correct. It's not<br>
amateur hour.<br></blockquote></div><div class="gmail_extra"><br></div>Let's keep this polite.  I'll err on the side of bumping the build number in the future.<br clear="all"><div><br></div>-- <br>Steve Borho
</div></div>