# HG changeset patch
# User Satoshi Nakagawa nakagawa...@oki.com
# Date 1392710845 -32400
# Tue Feb 18 17:07:25 2014 +0900
# Node ID d0e59351624e8487780db32247be34e4a2cc5984
# Parent 8571d160aedb00e07a3f47016f04d8d9aeaa5856
nextState table
diff -r 8571d160aedb -r d0e59351624e
# HG changeset patch
# User Deepthi Nandakumar deep...@multicorewareinc.com
# Date 1392719910 -19800
# Node ID fcbe566424bc238ec5129fe162206817d3e639be
# Parent 7b5b3a5475a7797db6f6dc8f5679eb60ef28a8fa
ratecontrol: change RateControl::lastSatd to currentSatd, add comments
diff -r 7b5b3a5475a7 -r
Just the last 2 examples of encoding 60 seconds from ToS in 1080p:
a) CRF 24 = 11402140 B * 8 b/B : 60 s = 1520.3 kbps (x265 reports 7597.54
in CSV)
b) CRF 18 = 26700793 B * 8 b/B : 60 s = 3560.1 kbps (x265 reports
17796.64 in CSV)
It seems that x265 reports about 5x the bitrate of the
I ran a loop of encodes through all presets (all default options) with
Sintel Trailer in 640x272 as Y4M source (YUV 4:2:0).
During all presets {slow..placebo}, x265 0.7+207-1be6b8c8b9ed [GCC 4.8.2,
Win64] crashed at different frames, usually around 120/1247, already at
29/1247 for preset
@ the MCW x265 team:
wouldn't it be the time to setup a testbot or something?
= ORIGINAL MESSAGE BELOW =
--- cont...@ligh.de wrote:
From: Mario *LigH* Rohkrämer cont...@ligh.de
To: Development for x265 x265-devel@videolan.org
Subject: [x265] APPCRASH in x265 0.7+207 while encoding in
So.
https://bitbucket.org/multicoreware/x265/commits/b1f5fd61883a0f375bbb5012fc41a5661c0b9389
This introduced an API change with NO version bump.
People complained stuff no longer builds.
https://bitbucket.org/multicoreware/x265/commits/ce96cdb390fe26aee6effa731e51303c1d9056b0
Fixed it in the
On 18 Feb 2014, at 08:44, Steve Borho st...@borho.org wrote:
# HG changeset patch
# User Steve Borho st...@borho.org
# Date 1392704518 21600
# Tue Feb 18 00:21:58 2014 -0600
# Node ID 3512dec4936ea2d6346587ede59b61e3c5c1b3c9
# Parent 8571d160aedb00e07a3f47016f04d8d9aeaa5856
api: add
On Tue, Feb 18, 2014 at 2:40 AM, Mario *LigH* Rohkrämer cont...@ligh.dewrote:
Am 18.02.2014, 02:53 Uhr, schrieb Steve Borho st...@borho.org:
On Mon, Feb 17, 2014 at 8:48 AM, Mario *LigH* Rohkrämer cont...@ligh.de
wrote:
Maybe too optimistic, it appears to crash:
+
Q:\Video\Tears of
On Tue, Feb 18, 2014 at 6:55 AM, Mario *LigH* Rohkrämer cont...@ligh.dewrote:
Just the last 2 examples of encoding 60 seconds from ToS in 1080p:
a) CRF 24 = 11402140 B * 8 b/B : 60 s = 1520.3 kbps (x265 reports 7597.54
in CSV)
b) CRF 18 = 26700793 B * 8 b/B : 60 s = 3560.1 kbps (x265 reports
On Tue, Feb 18, 2014 at 8:33 AM, JMK three4tee...@coldmail.nu wrote:
@ the MCW x265 team:
wouldn't it be the time to setup a testbot or something?
we do; and we've found that the 4:4:4 changes caused problems for 10bit
builds that we're looking through.
Are you using a HIGH_BIT_DEPTH build,
On Tue, Feb 18, 2014 at 9:46 AM, Derek Buitenhuis
derek.buitenh...@gmail.com 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
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
On Tue, Feb 18, 2014 at 12:09 PM, Derek Buitenhuis
derek.buitenh...@gmail.com 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.
On 2/18/2014 6:36 PM, Steve Borho wrote:
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?
I can currently lock it into a version range. Right
On Tue, Feb 18, 2014 at 12:59 PM, Derek Buitenhuis
derek.buitenh...@gmail.com wrote:
On 2/18/2014 6:36 PM, Steve Borho wrote:
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
Has this been fixed? Murugan - have you reproduced/fixed this issue?
On Sat, Feb 15, 2014 at 12:13 AM, Steve Borho st...@borho.org wrote:
On Fri, Feb 14, 2014 at 12:39 PM, Steve Borho st...@borho.org wrote:
On Fri, Feb 14, 2014 at 4:41 AM, dnyanesh...@multicorewareinc.comwrote:
# HG
I have also checked on Mac machine, I am not getting dequant failure. I
will send patch again, as this will not apply on latest tip.
---
Dnyaneshwar G
On Wed, Feb 19, 2014 at 9:57 AM, Murugan Vairavel
muru...@multicorewareinc.com wrote:
Hi Deepthi,
I tried to reproduce this , but it is
Am 18.02.2014, 18:34 Uhr, schrieb Steve Borho st...@borho.org:
On Tue, Feb 18, 2014 at 8:33 AM, JMK three4tee...@coldmail.nu wrote:
@ the MCW x265 team:
wouldn't it be the time to setup a testbot or something?
we do; and we've found that the 4:4:4 changes caused problems for 10bit
builds
# HG changeset patch
# User Dnyaneshwar G dnyanesh...@multicorewareinc.com
# Date 1392792673 -19800
# Wed Feb 19 12:21:13 2014 +0530
# Node ID 6150985c3d535f0ea7a1dc0b8f3c69e65e30d25b
# Parent 1a0d5b456b19e8f187290c662425080cfc870492
asm: added 16bpp support for dct[4x4, 8x8], idct4x4,
On Wed, Feb 19, 2014 at 1:04 AM, dnyanesh...@multicorewareinc.com wrote:
# HG changeset patch
# User Dnyaneshwar G dnyanesh...@multicorewareinc.com
# Date 1392792673 -19800
# Wed Feb 19 12:21:13 2014 +0530
# Node ID 6150985c3d535f0ea7a1dc0b8f3c69e65e30d25b
# Parent
20 matches
Mail list logo
