On Sat, Jan 30, 2016 at 05:52:24PM +, Derek Buitenhuis wrote:
> On 1/27/2016 6:18 PM, Stephen Hutchinson wrote:
> > I have no strong opinion on it. 68 seems like the compromise
> > position since it'd allow both 1.8 and 1.9 to be used, whereas
> > any of the earlier ones still fall within 1.8'
On 1/27/2016 6:18 PM, Stephen Hutchinson wrote:
> I have no strong opinion on it. 68 seems like the compromise
> position since it'd allow both 1.8 and 1.9 to be used, whereas
> any of the earlier ones still fall within 1.8's dev cycle and would
> only be used by those users making builds against
On 1/27/2016 10:48 AM, Derek Buitenhuis wrote:
On 1/27/2016 12:10 AM, Stephen Hutchinson wrote:
The configure detection is bumped to X265_BUILD >= 68,
since API version 68 corresponds with the x265 1.8
release tarball.
Was 68 the first API version it was in, or merely the tarball?
I would pre
On 1/27/2016 12:10 AM, Stephen Hutchinson wrote:
> The configure detection is bumped to X265_BUILD >= 68,
> since API version 68 corresponds with the x265 1.8
> release tarball.
Was 68 the first API version it was in, or merely the tarball?
I would prefer the actual version it was introduced in (
The configure detection is bumped to X265_BUILD >= 68,
since API version 68 corresponds with the x265 1.8
release tarball. The warnings inside x265 about
12-bit being experimental were removed prior to API
version 72 a short time later. At this time of
writing, X265_BUILD is at version 80.
12-bit
On 8/22/2015 7:17 PM, Stephen Hutchinson wrote:
> This was introduced in x265 in July, and the experimental warnings
> about it in libx265 were recently removed, so there shouldn't be
> any reason to have it as experimental here.
>
> The configure detection is bumped to X265_BUILD >= 60, as the
>
On 22/08/15 10:03 PM, Stephen Hutchinson wrote:
>> I don't really think checking for 60 is enough to get working 12bit
>> non-experimental encoding. 68 will probably be a safer bet.
>> And regardless of which we end up checking for, this change will break
>> support for libx265 1.7, which is not a
On 8/22/2015 3:26 PM, James Almer wrote:
The warnings were removed from the master branch of libx265 three days
ago, and X265_BUILD in that branch is 71.
libx265 1.8 will be tagged from the stable branch in the coming days,
which is not up to date with master (X265_BUILD is 68) and of course
mean
On 22/08/15 3:17 PM, Stephen Hutchinson wrote:
> This was introduced in x265 in July, and the experimental warnings
> about it in libx265 were recently removed, so there shouldn't be
> any reason to have it as experimental here.
>
> The configure detection is bumped to X265_BUILD >= 60, as the
> r
This was introduced in x265 in July, and the experimental warnings
about it in libx265 were recently removed, so there shouldn't be
any reason to have it as experimental here.
The configure detection is bumped to X265_BUILD >= 60, as the
requisite 12-bit querying ability in x265_api_get was added
10 matches
Mail list logo
