Re: [x265] [PATCH] TComDataCU: replace getZorderIdxInCU() with encodeIdx of CU structure

Crashes at medium preset. ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] primitives: intra_pred[4][35] = intra_pred[35][4] (avoid *35)

Hi, This causes an error in our regression tests, within X265_FREE(m_predBuf). Please take a look at this. Thanks, Deepthi On Fri, Sep 19, 2014 at 1:08 PM, Satoshi Nakagawa nakagawa...@oki.com wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 142115 -32400

Re: [x265] [PATCH] asm: replace mova by movu to avoid AVX2 testbench crash in dct16, dct32, denoise_dct, its same speed on Haswell

Thanks, Min. Pushed. However, I still get the testbench error message - quantcoeff/dequantcoeff buffer not aligned. Does the above change need to be reflected to quant/dequant also? Thanks, Deepthi On Wed, Sep 24, 2014 at 12:50 AM, Min Chen chenm...@163.com wrote: # HG changeset patch # User

Re: [x265] [PATCH] TComDataCU: replace getZorderIdxInCU() with encodeIdx of CU structure

Thanks. Since we're doing cuData-encodeIdx * 4 everywhere, any reason why we cant just save this value - so repeated shifts can be avoided. encodeIdx can be downshifted where needed. ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] [PATCH] Changes for loadCTUData

Ashok/Santhoshini - pls review. Does removing offsets affect any planned optimizations? On Sat, Sep 27, 2014 at 7:03 AM, dtyx...@gmail.com wrote: # HG changeset patch # User David T Yuen dtyx...@gmail.com # Date 1411781537 25200 # Node ID 85098db291ae133981419868685358227b8b1437 # Parent

Re: [x265] [PATCH] rc: correct the threshold for resetABR function

Thanks, this is the right patch. Steve, can you pls push this logic? My internet connection gave up on me right after I pushed the wrong one - talk about luck On Oct 2, 2014 12:47 AM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1412190970 -19800 #

Re: [x265] [PATCH] rc: use a sliding window to calculate moving avg SatdCost for ABR Reset logic

On Sun, Oct 5, 2014 at 5:08 PM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1412460518 -19800 # Sun Oct 05 03:38:38 2014 +0530 # Node ID 41cb94e538b800d8792fac48ceb9f8bdf2a9f627 # Parent b6d49505b179cb509aa76f3a065192f0b4926579 rc: use a

Re: [x265] [PATCH] noiseReduction: make noiseReduction deterministic

Yup, TComPicSym or even Frame should be fine - since every Frame will be associated with one FrameEncoder at start of encode. On Tue, Oct 14, 2014 at 11:45 AM, Steve Borho st...@borho.org wrote: On 10/14, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi Nandakumar

Re: [x265] [PATCH] noiseReduction: make noiseReduction deterministic for a given number of frameEncoders

wrote: # HG changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com # Date 1413278604 -19800 # Tue Oct 14 14:53:24 2014 +0530 # Node ID c6e786dbbfaa39822799d17e6c32d49c6141a7fb # Parent 38b5733cc629dd16db770e6a93b4f994e13336f3 noiseReduction: make noiseReduction

Re: [x265] [PATCH] noiseReduction: make noiseReduction deterministic for a given number of frameEncoders

Aah, you' re right. In my older patch, the encoder was initialising threadLocalData.nr . Somehow, I missed that while making the new patch. On Wed, Oct 15, 2014 at 12:41 AM, Steve Borho st...@borho.org wrote: On 10/14, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi

Re: [x265] [PATCH] search: dump the best motion statistics for PB slices into analysisdata file

The satdCost returned by motionEstimate already has the mv cost added to it. You need to subtract mvcost from this to set the bool correctly. On Wed, Oct 15, 2014 at 10:10 AM, Gopu Govindaswamy g...@multicorewareinc.com wrote: On Wed, Oct 15, 2014 at 12:44 AM, Steve Borho st...@borho.org

Re: [x265] [PATCH 1 of 1] search: change psy-rd energy and cost measurement

20, 2014 at 10:54 PM, Steve Borho st...@borho.org wrote: On 10/20, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com # Date 1413805233 -19800 # Mon Oct 20 17:10:33 2014 +0530 # Node ID

Re: [x265] cleanup CUData::m_skipFlag

Thanks - looks good. On Mon, Nov 3, 2014 at 1:35 PM, Satoshi Nakagawa nakagawa...@oki.com wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1415001734 -32400 # Mon Nov 03 17:02:14 2014 +0900 # Node ID ef411645295a51cf276e7830d9a98ffe50d85f63 # Parent

Re: [x265] cleanup CUData::m_skipFlag

On Mon, Nov 3, 2014 at 1:35 PM, Satoshi Nakagawa nakagawa...@oki.com wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1415001734 -32400 # Mon Nov 03 17:02:14 2014 +0900 # Node ID ef411645295a51cf276e7830d9a98ffe50d85f63 # Parent

Re: [x265] [PATCH 1/2] Add entropy coder support for tile header generation

We do not foresee tile level parallelism in the near future. With pmode, this has become even less desirable, since we're able to improve utilization without sacrificing efficiency. A few months ago, we removed exactly similar code with tile headers. We'd rather not add unused features back in,

Re: [x265] fix typo

Good catch, thanks. On Fri, Nov 7, 2014 at 1:58 PM, Satoshi Nakagawa nakagawa...@oki.com wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1415348521 -32400 # Fri Nov 07 17:22:01 2014 +0900 # Node ID ddc90f87dbe7dd704e9f0b0fe15c4752f9156c16 # Parent

Re: [x265] fix bug in 522baf03fbbd

Thanks, Satoshi. pushed. On Fri, Nov 7, 2014 at 4:01 PM, Satoshi Nakagawa nakagawa...@oki.com wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1415356167 -32400 # Fri Nov 07 19:29:27 2014 +0900 # Node ID cdb4f8e542d3d37710464ecc8279469024d24584 # Parent

Re: [x265] [PATCH] cli: add numPredMode into analysis structure and keep configurable based on param

Analysis load/save is being fully refactored. The earlier 2 patches have been queued, but I'll wait on this one. On Tue, Nov 11, 2014 at 12:38 PM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1415689681 -19800 # Tue Nov

Re: [x265] [PATCH] search: fix binary mismatch and inconsistent crash for share inter information

MVs are no longer shared or reused, but are instead re-computed? On Mon, Nov 17, 2014 at 3:36 PM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1416218723 -19800 # Mon Nov 17 15:35:23 2014 +0530 # Node ID

Re: [x265] [PATCH] rc: fix chroma qp and chroma lambda derivations

This looks like a Main bug where rdcost was not looking at g_chromaScale at all. On Thu, Dec 4, 2014 at 4:36 PM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1417675781 -19800 # Thu Dec 04 12:19:41 2014 +0530 # Node ID

Re: [x265] [PATCH] rc: fix chroma qp and chroma lambda derivations

Is there an if (csp == I420) wrapper specified though? For some reason, deblock/quant have this. On Thu, Dec 4, 2014 at 4:50 PM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: This looks like a Main bug where rdcost was not looking at g_chromaScale at all. On Thu, Dec 4, 2014 at 4

Re: [x265] fix chroma distortion for 4:2:2

Thanks, good catch - pushed. On Fri, Dec 5, 2014 at 9:43 AM, Satoshi Nakagawa nakagawa...@oki.com wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1417752745 -32400 # Fri Dec 05 13:12:25 2014 +0900 # Node ID 1c46b37e0d8051859ed2b5ab7f4c4ed0c72fc84e #

Re: [x265] [PATCH Review Only] chroma_hpp[8x8] for colorspace i420 in avx2: improve 541c-339c

The parent doesn't exist in the public repo, so I cannot apply this patch. Please rebase and send again. On Mon, Dec 8, 2014 at 3:29 PM, aasaipr...@multicorewareinc.com wrote: # HG changeset patch # User Aasaipriya Chandran aasaipr...@multicorewareinc.com # Date 1418032695 -19800 # Mon

Re: [x265] [PATCH Review only] asm: chroma_vpp[16x16] for colorspace i420 in avx2: improve 998c-978c

Henceforth, when sending multiple patches, it's better to have them based one after another, rather than all on the same tip. On Mon, Dec 8, 2014 at 11:22 PM, chen chenm...@163.com wrote: its right At 2014-12-08 20:11:35,Divya Manivannan di...@multicorewareinc.com wrote: # HG changeset patch

Re: [x265] [PATCH Review only] asm: chroma_vpp[16x16] for colorspace i420 in avx2: improve 998c-978c

Sorry, didnt realise my complicated merge changed the username. Sorry about that. On Tue, Dec 9, 2014 at 6:03 AM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: Henceforth, when sending multiple patches, it's better to have them based one after another, rather than all on the same tip

Re: [x265] x265 -- YASM 1.3.0 update

Thanks for pointing us to the YASM update. We will update our pages shortly. On Wed, Sep 24, 2014 at 12:11 AM, Michal Powalko m.powa...@gmail.com wrote: Hi x265 developers, On the bitbucket site You are pointing out the those information about YASM 1.2.0: - To ensure your build of

Re: [x265] [PATCH Review only] asm: added psy_acEnergy_pp_4x4 in sse4 for psyCost_pp

Psy-energy is not always measured at the CU level. estIntraPredQT makes RD decisions at the PU level (search.cpp: 1532). Also, chroma uses the psy-rd 4x4 cost loop for 8x8 CUs. I see the concern though about performance reduction due to an in-loop if (size) check. There's no neat way around this,

Re: [x265] [PATCH Review only] asm: added psy_acEnergy_pp_4x4 in sse4 for psyCost_pp

Ok, We just discussed this here - we'll have function pointers initialised based on size (match up the 4x4 and non-4x4 funcdef primitives using some assembly tricks Praveen suggested). On Thu, Dec 18, 2014 at 2:50 PM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: Psy-energy

Re: [x265] [PATCH] analysis: dump the best depth and re-use it for analysis-mode=load

On Mon, Dec 22, 2014 at 4:59 PM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1419247700 -19800 # Mon Dec 22 16:58:20 2014 +0530 # Node ID 8606c4019f6b962bec47398ac8f876642ecab747 # Parent

Re: [x265] [PATCH] Basic support for tweaking rate control using zones

Hi, Thanks for your patch. I'm not quite sure any of our regular users need this as of now. We will keep this on standby though - until any requests come in. On Mon, Dec 22, 2014 at 6:09 AM, Adam Marcus adampetermar...@gmail.com wrote: # HG changeset patch # User amarcu5

Re: [x265] [PATCH] encoder: allocate memory for inter and intra analysis data based on slicetype

Thanks, pushed with an additional comment. On Tue, Dec 23, 2014 at 12:18 PM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1419317228 -19800 # Tue Dec 23 12:17:08 2014 +0530 # Node ID

Re: [x265] rdcost: unify scaleChromaDist*()

Thanks, pushed. On Tue, Dec 23, 2014 at 2:13 PM, Satoshi Nakagawa nakagawa...@oki.com wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1419324053 -32400 # Tue Dec 23 17:40:53 2014 +0900 # Node ID 36bde0fab6510684879e6ad996ab7d5acab86a5e # Parent

Re: [x265] [PATCH] analysis: simplify inter analysis structure to share more inter analysis data

On Wed, Dec 24, 2014 at 10:35 AM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1419397499 -19800 # Wed Dec 24 10:34:59 2014 +0530 # Node ID f75dc9609ebc8a6ca32921b352a55831e7dd199e # Parent

Re: [x265] [PATCH] entropy: inline codeTransformSkipFlags()

Thanks, pushed. On Wed, Dec 24, 2014 at 12:53 PM, as...@multicorewareinc.com wrote: # HG changeset patch # User Ashok Kumar Mishraas...@multicorewareinc.com # Date 1419404487 -19800 # Wed Dec 24 12:31:27 2014 +0530 # Node ID 1bf769c6953d7c4f660d26a8618083ac1c0885e5 # Parent

Re: [x265] [PATCH] Added cmake support to pass along build flags to yasm

Thanks, pushed. On Tue, Dec 30, 2014 at 3:02 AM, dtyx...@gmail.com wrote: # HG changeset patch # User David T Yuen dtyx...@gmail.com # Date 1419888680 28800 # Node ID 143f81ed72f166dee5df756deb0e1de5c83f5949 # Parent 38d2d0878acd2029e76dfa76c96c3f7eb1818e71 Added cmake support to pass

Re: [x265] [PATCH] asm: psyCost_pp_8x8 in sse4: improve 6425c-928c

Pushed with newline fix. On Tue, Dec 30, 2014 at 4:26 PM, chen chenm...@163.com wrote: right now. please don't insert blank line before RET in next time. At 2014-12-30 17:05:31,Divya Manivannan di...@multicorewareinc.com wrote: # HG changeset patch # User Divya Manivannan

Re: [x265] [PATCH 2 of 2] rc: restrict low tolerance for bitrate fluctuations to strict-cbr option

On Tue, Dec 30, 2014 at 2:51 PM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1419064540 -19800 # Sat Dec 20 14:05:40 2014 +0530 # Node ID fa8ab4bd8851613983e152e682c031fd4b0e83e8 # Parent 98dfd6e0c72122e8613208d5927a4c81da6a8e7a rc:

Re: [x265] [PATCH] fix build error, add definition for getICRateNegDiff

Thanks, pushed. On Thu, Feb 5, 2015 at 11:49 AM, santhosh...@multicorewareinc.com wrote: # HG changeset patch # User Santhoshini Sekarsanthosh...@multicorewareinc.com # Date 1423117093 -19800 # Thu Feb 05 11:48:13 2015 +0530 # Node ID bd4febc33ccc0a51228bc4884c7a5287fea8fea8 # Parent

Re: [x265] [PATCH] threading: use InterlockedExchangeAdd for ATOMIC_ADD

Thanks, pushed with an updated commit message On Mon, Feb 2, 2015 at 2:35 PM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1422867856 -19800 # Mon Feb 02 14:34:16 2015 +0530 # Node ID

Re: [x265] Questions about parallelism

Hello, First, glad to know we've got company analyzing performance issues on x265! Hopefully, this will lead to lots of good ideas. On Mon, Feb 2, 2015 at 3:36 PM, Nicolas Morey-Chaisemartin nmo...@kalray.eu wrote: Hi, I've been elbow-deep in the overall parallelism of x265 these last few

Re: [x265] Patch 9239 (46c767f4eb46) is incomplete for cli.rst

Fix pushed. On Mon, Feb 2, 2015 at 1:18 PM, Mario *LigH* Rohkrämer cont...@ligh.de wrote: You proposed: + @@ -804,7 +804,7 @@ has effect on slower presets which use RDO Quantization (:option:`--rd` 4, 5 and 6). 1.0 is a typical value. Default disabled. High

Re: [x265] [PATCH] analysis: dump and reuse the bestmergeCand for skip and merge mode

On Mon, Feb 2, 2015 at 10:23 AM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1422852790 -19800 # Mon Feb 02 10:23:10 2015 +0530 # Node ID db56dc779466c5b54a55b5dadbcd04e882011729 # Parent

Re: [x265] [PATCH] asm: idct16 intrinsic 28900-25000 improvement over previous intrinsic

Thanks, pushed. We appreciate all help in accelerating 16/32 DCT/IDCT primitives. On Mon, Jan 19, 2015 at 11:14 PM, dtyx...@gmail.com wrote: # HG changeset patch # User David T Yuen dtyx...@gmail.com # Date 1421689416 28800 # Node ID fd4481542b452a01b790ab677e6a7209675b965b # Parent

Re: [x265] [PATCH 2 of 2] asm: rewrite and fix bug in weight_sp_sse4 on HIGH_BIT_DEPTH mode

Thanks, Min. Pushed. On Mon, Jan 19, 2015 at 3:52 PM, Min Chen chenm...@163.com wrote: # HG changeset patch # User Min Chen chenm...@163.com # Date 1421662910 -28800 # Node ID b2f64dbe26392dd6bea2badaccf2869bec883392 # Parent a0bb3bb1b076d2ef559ab94bfe81052142d302c3 asm: rewrite and fix

Re: [x265] [PATCH] asm: psyCost_ss_64x64 in sse4: improve 501123c-159906c

Thanks, pushed this series 2015-01-19 11:17 GMT+05:30 Divya Manivannan di...@multicorewareinc.com: # HG changeset patch # User Divya Manivannan di...@multicorewareinc.com # Date 1421646391 -19800 # Mon Jan 19 11:16:31 2015 +0530 # Node ID 1819b33631db227007283d952cbea22759012756 #

Re: [x265] [PATCH 2 of 3] implementation for minimum CU size

I agree. Santhoshini, except for the whitespace fixes and set_globals addition, no changes should be necessary. The max depth is set in SPS already. On Tue, Feb 17, 2015 at 11:14 AM, Steve Borho st...@borho.org wrote: On 02/16, santhosh...@multicorewareinc.com wrote: # HG changeset patch #

Re: [x265] [PATCH 3 of 3] CLI: add new option cu-min(minimum CU size)

Here, wouldnt it be better to call this --min-cu-size to go with the --max-tu-size introduced earlier? On Mon, Feb 16, 2015 at 4:55 PM, santhosh...@multicorewareinc.com wrote: # HG changeset patch # User Santhoshini Sekarsanthosh...@multicorewareinc.com # Date 1424075543 -19800 # Mon

Re: [x265] [PATCH] analysis: simplify inter analysis structure to share more inter analysis data

Pushed - with the following change On Thu, Jan 8, 2015 at 5:35 PM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1419397499 -19800 # Wed Dec 24 10:34:59 2014 +0530 # Node ID 24da7b0accdafb1f9e7e54182c114cb264d09bab #

Re: [x265] [PATCH 1 of 3] cli: remove tune cbr and introduce strict-cbr as a param option instead

Queued, with some fixups below On Mon, Jan 12, 2015 at 11:18 AM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1419332550 -19800 # Tue Dec 23 16:32:30 2014 +0530 # Node ID 4f8a105102a7984226e62ce7ac8f149a7a9c747f # Parent

Re: [x265] [PATCH] TestBench-check_quant_primitive: fix transform size

Hi, pushed an equivalent patch. The quant testbench fails on the tip as of now. On Mon, Feb 16, 2015 at 3:53 PM, prav...@multicorewareinc.com wrote: # HG changeset patch # User Praveen Tiwari prav...@multicorewareinc.com # Date 1424082194 -19800 # Node ID

Re: [x265] [PATCH] slicetype: fix the BRef cost estimates in vbv lookahead

Thanks, queued for testing. On Mon, Feb 16, 2015 at 12:18 PM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1424063038 -19800 # Mon Feb 16 10:33:58 2015 +0530 # Node ID 540697e77bbce88e1065035d41b5222da45318cb # Parent

Re: [x265] [PATCH] fix bug in satd_4x4 for psyCost_ss

Ok - for HBD enabled, this needs to be 64-bit, so this patch can be pushed. The asm will use 32/64 bit as appropriate. On Thu, Jan 8, 2015 at 3:44 PM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: Divya will send a corrected patch for this, the intermediate values can stay as 32-bit

Re: [x265] [PATCH] fix bug in satd_4x4 for psyCost_ss

Divya will send a corrected patch for this, the intermediate values can stay as 32-bit. On Thu, Jan 8, 2015 at 2:01 PM, Divya Manivannan di...@multicorewareinc.com wrote: # HG changeset patch # User Divya Manivannan di...@multicorewareinc.com # Date 1420705817 -19800 # Thu Jan 08

Re: [x265] [PATCH] quant[BUG]: correct scaling list type

changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com # Date 1426664785 -19800 # Wed Mar 18 13:16:25 2015 +0530 # Node ID 3a913041edebc6198c78800b63337d3c5afe8f1e # Parent 14aec6dc4d3b6c7b295fe1ead34c0f9f89a08cc4 quant[BUG]: correct scaling list type how did

Re: [x265] [PATCH] revert unintended comments in 638a3af86fa1

Thanks, pushed with a commit message fix On Wed, Mar 18, 2015 at 8:09 AM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1426646352 -19800 # Wed Mar 18 08:09:12 2015 +0530 # Node ID c92fd0798e71e72c18deef967fb7a95960d9bc27 # Parent

Re: [x265] [PATCH] asm: luma_hps[32x8, 32x16, 32x24, 32x32, 32x64] avx2 - improved 6143c-3210c, 9343c-4767c, 12806c-6737c, 16065c-8648c, 29073c-15496c

This crashes on my system. Pls check. On Mon, Mar 16, 2015 at 11:03 AM, aasaipr...@multicorewareinc.com wrote: # HG changeset patch # User Aasaipriya Chandran aasaipr...@multicorewareinc.com # Date 1426483989 -19800 # Mon Mar 16 11:03:09 2015 +0530 # Node ID

Re: [x265] [PATCH] slicetype: fix crash when rc-lookahead = bframes

, Steve Borho st...@borho.org wrote: On 03/09, Deepthi Nandakumar wrote: slicetypeAnalyse::maxSearch also needs to be changed, or you could trigger another crash using --b-adapt 1. It seems to me, under the hood we're just incrementing lookaheadDepth. That may be the right thing to do here

Re: [x265] [PATCH] asm: avx2 code for sad_x3[8x4] for 8bpp - 41x

Thanks, Min. The point is that we need to measure the speedup relative to SSE3/AVX, the best that's already available, rather than measuring speedup against C-ref. On Tue, Mar 10, 2015 at 2:23 AM, chen chenm...@163.com wrote: MMX2 sad_x3[ 8x4] 15.44x 166.02 2562.99 AVX2

Re: [x265] [PATCH] rc: recompute planned frame size when using vbv with --qpfile

No, this is not. This is for a customer who wanted to be able to use qpfile with VBV. The first half is - I'm not sure about the second half of the patch. On Thu, Mar 12, 2015 at 1:44 AM, Steve Borho st...@borho.org wrote: On 03/11, aar...@multicorewareinc.com wrote: # HG changeset patch #

Re: [x265] [PATCH] slicetype: change the total CU value for averaging of qp_adj

This is an error introduced when we moved calcAdaptiveQuantFrame from ratecontrol to slicetype. ncu in ratecontrol signifies actual number of 16x16 blocks, whereas ncu in slicetype leaves out the border blocks (I think?) slicetype.cpp:481 (m_ncu = m_widthInCU 2 m_heightInCU 2 ? (m_widthInCU -

Re: [x265] [PATCH] slicetype: fix crash when rc-lookahead = bframes

slicetypeAnalyse::maxSearch also needs to be changed, or you could trigger another crash using --b-adapt 1. It seems to me, under the hood we're just incrementing lookaheadDepth. That may be the right thing to do here, or do a CHECK for lookaheadDepth = bframes? On Mon, Mar 9, 2015 at 12:25 PM,

Re: [x265] [PATCH] rc: recompute planned frame size when using vbv with --qpfile

On Wed, Mar 11, 2015 at 12:01 PM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1425994215 -19800 # Tue Mar 10 19:00:15 2015 +0530 # Node ID 9b7b93384e39e90cf2d4c0c0a53213abff362f70 # Parent 8f148ac8dbe4b68e88ceff84f40e33b29e888dc9 rc:

Re: [x265] [PATCH] analysis:add logic for calculate qp for a given cu size

I think the point is, m_cuTreeStats.qpBuffer contains the Fix8 values for 2-pass, but the m_lowres buffers keep double offsets for both AQ and cutree. We can push this patch, so Gopu can proceed with the rest of fine grained AQ. Sreelakshmy, your next task should be to modify both the double

Re: [x265] [PATCH] analysis: bidir/inter choice using sa8dCost

/11, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com # Date 1426065176 -19800 # Wed Mar 11 14:42:56 2015 +0530 # Node ID 7d8f7aadfb6d0af071d804a3eec1511cd00818c5 # Parent 37ec8002eba15ec3b7bf2b16a792af572b099078

Re: [x265] [PATCH] aq: implementation of fine-grained adaptive quantization

Ok, agree it's best to hold it. But this patch should not change outputs since the default aq-depth is still zero. On Tue, Mar 24, 2015 at 7:59 PM, Steve Borho st...@borho.org wrote: On 03/23, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy

Re: [x265] [PATCH] Fixed 32 bit bug in intrapred dc4 sse2

Thanks, pushed. On Thu, Feb 26, 2015 at 8:03 AM, dtyx...@gmail.com wrote: # HG changeset patch # User David T Yuen dtyx...@gmail.com # Date 1424917924 28800 # Node ID 13346cb90bff040492f0688226f44182bb6b97d8 # Parent 74c716607444c77b9d5ea1dce5b99c875f0b20fe Fixed 32 bit bug in intrapred

Re: [x265] [PATCH] dqp: add logic to encode DQP at depth zero and above as well

Thanks, looks good. THis patch is not expected to change outputs in any way - so we need to watch out for regressions. When the RDO cost of DQP bits is included, the mode costs should be updated after the checkDQP and checkDQPForSplitPred functions, not before. On Thu, Mar 5, 2015 at 1:03 PM,

Re: [x265] [PATCH] disable SIGPIPE on Windows platform

Thanks, pushed. On Tue, Apr 14, 2015 at 11:22 AM, Xinyue Lu maill...@7086.in wrote: 在 2015/4/13 22:41, Min Chen 写道: # HG changeset patch # User Min Chen chenm...@163.com # Date 1428990100 -28800 # Node ID 4987a630b0d12638c1994afc7c21b9bc44282498 # Parent

Re: [x265] [PATCH] asm: interp_8tap_horiz pp and ps sse2

This crashed the test bench on my Windows Haswell machine On Wed, Apr 29, 2015 at 11:10 AM, chen chenm...@163.com wrote: right now, thanks At 2015-04-29 10:15:23,dtyx...@gmail.com wrote: # HG changeset patch # User David T Yuen dtyx...@gmail.com # Date 1430273620 25200 # Node ID

Re: [x265] Proposed solution to mixed 8/10 bit libraries

Hello Derek, We've enhanced x265 with the x265_api functionality to allow applications to choose between 8bpp and 16bpp encoders at runtime. Is this something ffmpeg would like to adopt? On Wed, Apr 1, 2015 at 2:33 AM, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 3/31/2015 8:33 PM,

Re: [x265] [PATCH 3 of 4] cli: allow -P/--profile to influence requested API bit-depth

, how'd you distinguish between 10 and 12 bit by --high-bit-depth? (And I'm not sure if HIGH_BIT_DEPTH flag will work on 12 bit though) On Tue, Apr 28, 2015 at 8:34 PM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: I see Xinyue's confusion about profile influencing bit depth. Another

Re: [x265] [PATCH 3 of 4] cli: allow -P/--profile to influence requested API bit-depth

work as before. On Wed, Apr 29, 2015 at 12:53 PM, Xinyue Lu maill...@7086.in wrote: If eventually we'll need --high-bit-depth 10/12/14, why not just use --output-depth 10/12/14 instead? ;) On Wed, Apr 29, 2015 at 12:21 AM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: Right, when we

Re: [x265] [PATCH 3 of 4] cli: allow -P/--profile to influence requested API bit-depth

I see Xinyue's confusion about profile influencing bit depth. Another issue is output-depth will be confused with recon-depth. How about --high-bit-depth and --no-high-bit-depth to match directly with HIGH_BIT_DEPTH option used during compile time? Is it necessary/useful to give x265 CLI the

Re: [x265] [PATCH] asm: interp_8tap_horiz pp and ps sse2

Still crashes on windows x64 On Wed, Apr 29, 2015 at 8:54 PM, dtyx...@gmail.com wrote: # HG changeset patch # User David T Yuen dtyx...@gmail.com # Date 1430321025 25200 # Node ID 9a1b8b71bc997547044f42992e1eb7f3572f03f1 # Parent e9df93f380664932e7d6c7e85b2cae16cd5e1dcd asm:

Re: [x265] [PATCH 6 of 6 REV2] analysis: always configure quant QP directly after setting RD lambda

Agreed, and the averaging should be weighted by CU block size. On Sun, Apr 26, 2015 at 11:17 PM, Steve Borho st...@borho.org wrote: On Sun, Apr 26, 2015 at 12:21 PM, Steve Borho st...@borho.org wrote: # HG changeset patch # User Steve Borho st...@borho.org # Date 1429943995 18000 #

Re: [x265] [PATCH] api: clarify docs and use of x265_api_get()

Ok, makes sense. Sending another patch which adds failures to api_get as well as clarifies usage. On Fri, May 1, 2015 at 11:37 PM, Steve Borho st...@borho.org wrote: On 04/30, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com

Re: [x265] [PATCH] search: add lowres MV into search mv candidate list for search ME

Thanks, will queue these for overnight testing. We discussed more improvements. 1. At 8x8, add the parent CU's corresponding lowres MV. 2. At higher depths, should we add an average of all child lowres MVs? Or add all child lowres MVs to the motion candidate list? On Wed, May 13, 2015 at

Re: [x265] [PATCH] search: add lowres MV into search mv candidate list for search ME(CHANGESOUTPUT)

Ran the smoke test on this, the results were mixed - on some commandlines, the encode efficiency benefits were really good though. On Thu, May 14, 2015 at 10:53 AM, g...@multicorewareinc.com wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1431581025

Re: [x265] [PATCH] search: add lowres MV into search mv candidate list for search ME(CHANGESOUTPUT)

do you need to add pu.width/2 ? Thanks, Deepthi On Mon, May 18, 2015 at 1:53 PM, Gopu Govindaswamy g...@multicorewareinc.com wrote: On Thu, May 14, 2015 at 8:18 PM, Steve Borho st...@borho.org wrote: On 05/14, Steve Borho wrote: On 05/14, Deepthi Nandakumar wrote: Ran the smoke test

Re: [x265] [PATCH] search: add lowres MV into search mv candidate list for search ME(CHANGESOUTPUT)

ok. Another thing we could check is, if restricting lowres MV candidates to 2Nx2N searches would give more consistent results. On Mon, May 18, 2015 at 8:04 PM, Steve Borho st...@borho.org wrote: On 05/18, Deepthi Nandakumar wrote: Gopu, initSubCU accounts for the CU's partIdx while

Re: [x265] [PATCH 0 of 3 ] asm: interp_4tap_vert_pp sse2

Thanks, but I cannot apply this patch. The parent-ID does not exist on the public tree. On Tue, May 12, 2015 at 7:21 AM, chen chenm...@163.com wrote: right ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] [PATCH] asm: improve algorithm logic on saoCuOrgE3

Min, pls resend. This conflicts with Divya's patch. On Wed, Apr 15, 2015 at 11:38 AM, Min Chen chenm...@163.com wrote: # HG changeset patch # User Min Chen chenm...@163.com # Date 1429078116 -28800 # Node ID 677ecdf2ba50e52604e73a1e92ea88ab26e950c1 # Parent

Re: [x265] [PATCH 0 of 3 ] asm: chroma_hpp for i422

Lets avoid this Patch 0 of ... unless you plan to add a description here. On Wed, Apr 15, 2015 at 2:41 PM, aasaipr...@multicorewareinc.com wrote: ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] asm: improve algorithm logic on saoCuOrgE3

Sorry, realised Steve had already pushed this. On Wed, Apr 15, 2015 at 3:58 PM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: Min, pls resend. This conflicts with Divya's patch. On Wed, Apr 15, 2015 at 11:38 AM, Min Chen chenm...@163.com wrote: # HG changeset patch # User Min

Re: [x265] Parameter --qgsize not functional?

Hello, It's *qg-size, *hyphen missing. On Tue, Apr 7, 2015 at 4:32 PM, Mario *LigH* Rohkrämer cont...@ligh.de wrote: x265 [info]: HEVC encoder version 1.6+117-095ed87526e5 x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp I tried to run a test with the following command line:

Re: [x265] [PATCH] aq: implementation of fine-grained adaptive quantization

st...@borho.org wrote: On 04/05, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com # Date 1427100822 -19800 # Mon Mar 23 14:23:42 2015 +0530 # Node ID d6e059bd8a9cd0cb9aad7444b1a141a59ac01193 # Parent

Re: [x265] [PATCH] aq: implementation of fine-grained adaptive quantization

else qp = m_qp[0][0], will not work, since you want the QP from the last allowed depth. eg, at 8x8 CU, you want the QP from the top-level 16x16 CU, not m_qp[0][0] which is the CTU averaged QP. On Mon, Apr 6, 2015 at 10:05 AM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: The initial

Re: [x265] [PATCH 2 of 2] aq: add cost of sub-LCU level QP to RD costs

how that can be done properly. Currently, this patch only changes outputs for rdLevels 4. I will send a follow-on patch which will also change outputs at the lower rdLevels, as it should. On Mon, Apr 6, 2015 at 3:49 PM, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi

Re: [x265] [PATCH] AQ/VBV: separate VBV cost accumulation from QP averaging for AQ

Ignore this cleanup patch. Something went wrong. On Sun, Apr 5, 2015 at 10:25 PM, deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com # Date 1428252902 -19800 # Sun Apr 05 22:25:02 2015 +0530 # Node ID

Re: [x265] [PATCH] aq: implementation of fine-grained adaptive quantization

Just reviewed this patch, and made the following changes. 1. Changed the depth parameter to QGSize. This is a lot simpler to explain and more intuitive to users since it correlates directly to the Quantization Group specified by the HEVC standard. 2. Fixed all explanations, commit messages and

Re: [x265] [PATCH] asm: removed duplicate constants

Thanks, there are already 2 patches with similar commit messages. Can you add more details to the commit message? On Wed, May 20, 2015 at 12:04 PM, dnyanesh...@multicorewareinc.com wrote: # HG changeset patch # User Dnyaneshwar G dnyanesh...@multicorewareinc.com # Date 1432102991 -19800 #

Re: [x265] [PATCH] analysis: re-order RD 0/4 analysis to do splits before ME or intra

Thanks. With the smoke tests, about 2/3rd of the tests show positive/neutral encode efficiency gains, while a third show marginally lower encode efficiency, with a couple of commandlines showing a surprising drop. On Tue, May 19, 2015 at 6:45 PM, as...@multicorewareinc.com wrote: # HG

Re: [x265] [PATCH] analysis: re-order RD 0/4 analysis to do splits before ME or intra

Ok, pushing this series in. After the additional patch, it's pretty much a win, especially the efficiency improvements in 10-bit are really solid. On Wed, May 20, 2015 at 4:09 PM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: Thanks. With the smoke tests, about 2/3rd of the tests

Re: [x265] [PATCH 1 of 6] asm: sse4 version of costCoeffGroupNxN in codeCoeffNxN

Thanks, Min. Sumalatha - can you please work on adding testbench support for the new codeCoeff primitive that has been added? On Fri, Jun 5, 2015 at 12:43 AM, Min Chen chenm...@163.com wrote: # HG changeset patch # User Min Chen chenm...@163.com # Date 1433445185 25200 # Node ID

Re: [x265] [PATCH] remove warnings or errors reported for mingw 16bpp

Thanks, a duplicate copy of this was pushed. On Fri, Jun 5, 2015 at 5:21 PM, sumala...@multicorewareinc.com wrote: # HG changeset patch # User Sumalatha Polureddy # Date 1433502818 -19800 # Fri Jun 05 16:43:38 2015 +0530 # Node ID 0a1500f84a4ef4721706638e75e226c31c7b102e # Parent

Re: [x265] [PATCH] asm: interp_4tap_horiz_pX sse3 10-bit

Hi, This throws build errors on a x86_64 Haswell machine. On Fri, Jun 5, 2015 at 8:23 PM, chen chenm...@163.com wrote: other is fine, we can push it, thanks At 2015-06-05 21:45:01,dave dtyx...@gmail.com wrote: I prefer to keep this patch as sse3/movdqu, is there anything holding this back?

Re: [x265] [PATCH] stats: rename fields of FrameStats structure

While we're in the renaming business, we might as well rename the percent variables also, to indicate clearly these are in 8x8 CU counts. On Fri, Jun 5, 2015 at 6:22 PM, Divya Manivannan di...@multicorewareinc.com wrote: # HG changeset patch # User Divya Manivannan di...@multicorewareinc.com

Re: [x265] [PATCH 6 of 6] asm: improve costCoeffRemain by bypass uncoded coeff

Min, thanks for this series of patches, all pushed. On Tue, Jun 9, 2015 at 11:36 PM, Min Chen chenm...@163.com wrote: # HG changeset patch # User Min Chen chenm...@163.com # Date 1433872879 25200 # Node ID e5b6f0a984bdd8ab16b63fb1c11a508a444515ec # Parent

Re: [x265] [PATCH] asm: interp_4tap_horiz_pX sse3 10-bit

dtyx...@gmail.com wrote: Can you post the errors? I am guessing I need to rebase this on the latest code and resubmit. On 06/08/2015 11:08 PM, Deepthi Nandakumar wrote: Hi, This throws build errors on a x86_64 Haswell machine. On Fri, Jun 5, 2015 at 8:23 PM, chen chenm...@163.com wrote

Re: [x265] [PATCH 0 of 3 RFC] further multilib improvements

Steve, the first patch in this series has not been emailed. On Sat, Jun 6, 2015 at 8:10 AM, Steve Borho st...@borho.org wrote: With these three patches, there is only a single remaining link conflict between the 8bit and 10bit libraries (g_entropyStateBits). To try these, create 8bit/ and

<    1   2   3   4   >