Re: [x265] v1.7 + >500 patches: new milestone in sight?

On 10/05, Mario *LigH* Rohkr?mer wrote: > No pressure. Just curious about your schedule. 1.8 has been eminant for some time, I expect it to happen in the next week or so. At some point we need to just tag it and move on. -- Steve Borho ___ x265-devel

[x265] [PATCH] add 64-byte alignment macro, align NR buffer & Encoder class to cache line of 64-byte

# HG changeset patch # User Dnyaneshwar G # Date 1444107449 -19800 # Tue Oct 06 10:27:29 2015 +0530 # Node ID 93525c471023575d500c912284a3853ee8df8991 # Parent f8b8ebdc54578e6735216d8b9abce5ba80c05bd8 add 64-byte alignment macro, align NR buffer & Encoder

Re: [x265] Adaptove GoP sizes - not sure if its working

Hi, I noticed another person seeing the constant GoP artifact in another thread.. I'm using version : x265 [info]: HEVC encoder version 1.7+431-f63273fa3137 x265 [info]: build info [Linux][GCC 4.8.4][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3

Re: [x265] Adaptove GoP sizes - not sure if its working

Hi Deepthi, I'm very sorry to open up this thread again after so long, but I tried enabling the debug log as you've said. And I get scenecut notifications such as : x265 [debug]: scene cut at 102 Icost:160729 Pcost:153370 ratio:0.0458 bias:5394.1909 gop:102 (imb:983 pmb:479) x265 [debug]: scene

Re: [x265] Adaptove GoP sizes - not sure if its working

Hi Xinyue, okay I will try r400 and r450 in that order..maybe tomorrow. I am using an action scene from the Matrix movie. 15 mins. But actually the behaviour is the same for all video streams i've tested on. Which was why I thought perhaps I am using the parameters incorrectly, or maybe its a

Re: [x265] v1.7 + >500 patches: new milestone in sight?

Hi - I was about to tag 1.8 yesterday, but the scenecut issue reported by Xinyue gave me pause. We tried reproducing it, and were not successful. So, I think we'll just go ahead and tag 1.8. On Mon, Oct 5, 2015 at 11:04 PM, Steve Borho wrote: > On 10/05, Mario *LigH* Rohkr?mer

Re: [x265] Adaptove GoP sizes - not sure if its working

Sorry - in b) below, it should be icost is greater than pcost. On Tue, Oct 6, 2015 at 6:56 AM, Deepthi Nandakumar < deep...@multicorewareinc.com> wrote: > We recently modified the scenecut logic slightly. There are 2 levels of > scenecuts detected > > a) One is where the I-frame cost is less

Re: [x265] Adaptove GoP sizes - not sure if its working

We recently modified the scenecut logic slightly. There are 2 levels of scenecuts detected a) One is where the I-frame cost is less than P-frame cost (with bias factor). This inserts an I-frame and is the scenecut everyone is familiar with. b) This next case is also logged as a scenecut - while

Re: [x265] Adaptove GoP sizes - not sure if its working

Hi, I think maybe it's better for me to leave comment in this thread. Here you are, including my builds, test video clips and the results. https://www.dropbox.com/s/6axpqr9wozeeqsu/x265%20patch%20test.tgz?dl=0 It should be clear to see that in rev437, I frames are inserted at 0, 250, 500,

[x265] [PATCH] asm: fix main12 avx2 for chroma_vpp/vps/vsp/vss

# HG changeset patch # User Rajesh Paulraj # Date 1444041513 -19800 # Mon Oct 05 16:08:33 2015 +0530 # Node ID 8dc9dfe33c370e5bc09863ab1062568662d46e37 # Parent 5f73ada8caa0c62cc7540799966bde7536861bf7 asm: fix main12 avx2 for chroma_vpp/vps/vsp/vss diff -r

[x265] [PATCH] include skip mode in lowres frame cost estimation

# HG changeset patch # User Sagar Kotecha # Date 1444046451 -19800 # Mon Oct 05 17:30:51 2015 +0530 # Node ID 8986245934895f0980128a571e982d8ee762cadb # Parent 6e7761bdfe23addb862483f8407b388800de7d92 include skip mode in lowres frame cost estimation diff -r

Re: [x265] [PATCH 1 of 2] slicetype: Modify Scenecut algorithm to detect scene transition points

Hello, We cannot reproduce this scene cut error. We tested with 4 different clips, and the current tip usually produces one I-slice less than the tip before this changeset. This is not necessarily a bug. We also tested all cases in both 8bpp and 10bpp modes, and the behaviour was fairly