Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

s-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> > > > On Sun, Nov 14, 2021 at 7:41 PM Derek Buitenhuis > wrote: > > On 11/1/2021 4:09 PM, Derek Buitenhuis wrote: > > Ping. >

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

On 11/1/2021 4:09 PM, Derek Buitenhuis wrote: > Ping. Ping. I've provided a definitive reference document, and this has been in prod, and made it through Dolby's bitsteam verifier. It's an extremely simple change. - Derek ___ x265-devel mailing l

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

On 10/12/2021 1:53 PM, Derek Buitenhuis wrote: > 8.4 is the same as the other profile 8s, except with an HLG base layer, > that is, CICP codepoint 18 (ARIB-STD-B67), as noted, for example, here > (embeds + contains PDF link): > > https://professionalsupport.dolby.com/s/articl

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

Hello, Reply below. On 10/12/2021 1:13 PM, Siva Viswanathan wrote: > We already started looking at it and we realized that we need 8.4 profile > spec to validate the implementation, hence the delay here > > Please share the relevant info 8.4 is the same as the other profile 8s, except with an

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

On 10/10/2021 11:51 AM, Derek Buitenhuis wrote: > Ping again - it is a very simple patch, an we've had it in production > for a while now. Third ping. I see that quite significant patches from MCW get OKed and pushed within minutes of hitting the mailing list. What I surmis

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

On 10/1/2021 11:36 AM, Derek Buitenhuis wrote: > Ping. Ping again - it is a very simple patch, an we've had it in production for a while now. - Derek ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add Dolby Vision 8.4 Profile Support

On Tuesday, September 28, 2021, Derek Buitenhuis wrote: > Signed-off-by: Derek Buitenhuis > --- > doc/reST/cli.rst | 2 +- > source/common/param.cpp| 8 > source/encoder/encoder.cpp | 3 ++- > 3 files changed, 7 insertions(+), 6 deletions(-

[x265] [PATCH] Add Dolby Vision 8.4 Profile Support

Signed-off-by: Derek Buitenhuis --- doc/reST/cli.rst | 2 +- source/common/param.cpp| 8 source/encoder/encoder.cpp | 3 ++- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/doc/reST/cli.rst b/doc/reST/cli.rst index b24fa72a9..56a94593a 100755 --- a/doc/reST

Re: [x265] [PATCH] Fix for build error in ffmpeg

On 25/07/2018 10:00, as...@multicorewareinc.com wrote: > --- a/source/x265.h Mon Jul 23 15:36:44 2018 +0530 > +++ b/source/x265.h Wed Jul 25 11:27:46 2018 +0530 > @@ -169,7 +169,7 @@ > uint32_t log2WeightDenom; > int inputWeight; > int inputOffset; > -bool

Re: [x265] [PATCH] Fix: Build error in VS 11

On 24/07/2018 18:48, Ashok Kumar Mishra wrote: > We have decided to back out the latest commit "Fix: Build error in VS 11", so > that it can solve the building issue in ffmpeg. > We are not going to support MSVC 11 anymore. Hi, As noted in my reply to j-b, my 2 cents is that this is still

Re: [x265] [PATCH] Fix: Build error in VS 11

On 23/07/2018 23:17, Jean-Baptiste Kempf wrote: > Proper fix is to use a correct toolchain, not a 5+ years one. > And if toolchain is broken, add a header there to work-around. You can argue that, but I think for a commercial thing like x265, it's a non-starter to require C99. Further, I am not

Re: [x265] [PATCH] Fix: Build error in VS 11

On 23/07/2018 13:19, Ashok Kumar Mishra wrote: > Pushed. This broke a lot of applications by now requiring users include stdbool.h before x265.h if they are using anything but MSVC. AKA it broke all non-MSVC builds. Proper fix is to not use bool in the header in the first place. - Derek

Re: [x265] [PATCH 1 of 2] Add support for customizing logging

On 3/18/2018 10:29 PM, Andrey Semashev wrote: > Normally, there is only one _application_. There may be multiple > _libraries_ using libx265 but none of them should be configuring its > logging, unless it is supposed to be the only one using libx265 in the > application (and generic libraries

Re: [x265] [PATCH 1 of 2] Add support for customizing logging

On 3/16/2018 3:28 PM, Andrey Semashev wrote: > +/* x265_set_log: > + * Sets a custom logger function */ > +void x265_set_log(x265_log_t log); I would like to voice my distaste for this implementation. This is a global callback, and will introduce problems with e.g. multiple libraries or

Re: [x265] unsigned promotion prevents encoding frames with negative strides

On 1/17/2018 4:31 PM, chen wrote: > Thank you report this bug. > I think the root cause is not sizeof(), the negative stride is invalid in > encoder/decoder core. > To avoid these invalid input parameters, the x264 insert a middle-layer that > convert color space and images, but x265 doesn't it.

Re: [x265] [PATCH] x265.h: change references into pointers for C compatibility

On 11/12/2017 8:30 PM, Ma0 wrote: > # HG changeset patch > # User Ma0 > # Date 1510517111 -3600 > # Sun Nov 12 21:05:11 2017 +0100 > # Node ID 06d89671aec95337c3b458985bd1f5361bf61bb0 > # Parent 563cbe1f4a21dcfe2117ccaa874b713d94434f92 > x265.h: change references

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

On 3/31/2015 8:33 PM, Steve Borho wrote: /* fill in provided x265_api structure with methods suited for * the provided encoder parameters. If 'p' is NULL you will get * the system default libx265 library methods */ void x265_get_api(x265_api* api, x265_param* p); Relevant chat from IRC:

Re: [x265] Fwd: Encoding question

On 1/20/2015 7:04 AM, Mario *LigH* Rohkrämer wrote: Encoding of partially covered motion is a pretty tough issue. MPEG-7 tries to model layers of shapes, but that's the next generation... For current encoders, more bitrate may be one of the best recommendations. I think what Sebastian was

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

On 12/23/2014 6:03 AM, Deepthi Nandakumar wrote: 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. Zones are fairly popular on e.g. Doom9 and within the the anime community. I don't really

Re: [x265] x265 ignores SAR (derived from Y4M header or as CLI flag)

On 11/4/2014 7:26 AM, Mario *LigH* Rohkrämer wrote: MPC-HC will probably rely on internal MediaInfo analysis results, so I'll have a look at their bug tracker. Out of curiosity, have you checked what ffmpeg or ffprobe say? - Derek ___ x265-devel

Re: [x265] x265 ignores SAR (derived from Y4M header or as CLI flag)

On 11/4/2014 1:36 PM, Mario *LigH* Rohkrämer wrote: ffprobe recognizes AR flags correctly, both in raw output and multiplexed into MP4 by MP4Box. [...] Some tools (like VLC) may prefer container flags and don't find any if MP4Box doesn't use any, possibly because it doesn't analyze HEVC

Re: [x265] use std::swap() for readability

On 7/9/2014 11:16 AM, Deepthi Nandakumar wrote: We spent a bunch of effort last year to remove STL dependencies, since they cause serious trouble between different compilers (even between different compiler versions). This is especially since a lot of users will use x265 as a static

Re: [x265] [PATCH] api: allow lambda tables to be user-specified via a text file

On 7/2/2014 11:22 PM, Steve Borho wrote: # HG changeset patch # User Steve Borho st...@borho.org # Date 1404339662 18000 # Wed Jul 02 17:21:02 2014 -0500 # Node ID 6da77093c4b2db20dfafa7ff5994294ba3773f24 # Parent b90fdc3ffb962ddd4baf1309a5d6ffa3908f0486 api: allow lambda tables to be

Re: [x265] [PATCH] api: allow lambda tables to be user-specified via a text file

On 7/3/2014 6:49 PM, Steve Borho wrote: Perhaps. It's mostly harmless when unused; but I imagine someone doing rate control / mode decision research would find it quite handy. At some point it'll probably get yanked, but there's no hurry for it. Cool. - Derek

Re: [x265] [PATCH] optimize and remove Pow() in processRowEncoder() to avoid VS2008 build error 'ambiguous...'

On 7/3/2014 7:40 PM, Min Chen wrote: -double scale = pow((double)2, g_maxCUSize / 16); +static const uint32_t scaleTable[] = {2, 4, 16}; +uint32_t scaleIndex = (g_convertToBit[g_maxCUSize] + 2 - 4); +double scale = (double)scaleTable[scaleIndex];

Re: [x265] [PATCH] optimize and remove Pow() in processRowEncoder() to avoid VS2008 build error 'ambiguous...'

On 7/3/2014 8:29 PM, chen wrote: At 2014-07-04 03:00:31,Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 7/3/2014 7:40 PM, Min Chen wrote: -double scale = pow((double)2, g_maxCUSize / 16); +static const uint32_t scaleTable[] = {2, 4, 16}; +uint32_t

Re: [x265] [PATCH] simplify: getLumaIntraDir()[x] - getLumaIntraDir(x)

On 7/2/2014 11:55 PM, Min Chen wrote: # HG changeset patch # User Min Chen chenm...@163.com # Date 1404341698 25200 # Node ID c239de820501daf4438a884f6bb6b30fff340789 # Parent e236f39a4293056fab686e0af76bb19748f4cef1 simplify: getLumaIntraDir()[x] - getLumaIntraDir(x) Looks reasonable if

Re: [x265] [PATCH] TComDataCU: remove redundant functions

On 7/3/2014 3:24 PM, as...@multicorewareinc.com wrote: # HG changeset patch # User Ashok Kumar Mishraas...@multicorewareinc.com # Date 1404283815 -19800 # Wed Jul 02 12:20:15 2014 +0530 # Node ID b546653344ca4f81845d44b2f0b86d56dcb853d3 # Parent e3f9acd4ff88eee82b7554baaab512bc1fd8e840

Re: [x265] [PATCH 1 of 2] improve count_nonzero by SSSE3

On 6/27/2014 4:05 PM, chen wrote: I can't understand what's your means. could you tell me more? I use some SSSE3 instruction and process 16 pixels every loop. I meant keep both sse2 and ssse3 variants. Not sure if x86inc.asm macros help with this or not. - Derek

Re: [x265] [PATCH 1 of 2] improve count_nonzero by SSSE3

On 6/27/2014 6:08 PM, chen wrote: I use ssse3 instruction PSHUFB to replace 3 SSE2 instructions, the x86inc macro can't handle it. After patch, this function is faster ~20% and codeCoeffNxN ~7% speedup, so I don't worry about old CPU's performance. I guess SSSE3 is very prevalent nowadays

Re: [x265] [PATCH 1 of 3] Chroma QP Offset: increase chroma QP when psy-rd is enabled

On 6/26/2014 6:35 AM, BugMaster wrote: That is separate --psy (--no-psy) option in x264 and not --psy-rd Yeah, that was my point. :) - Derek ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] cli: add --ipratio and --pbratio

On 6/26/2014 8:22 AM, Satoshi Nakagawa wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1403706071 -32400 # Wed Jun 25 23:21:11 2014 +0900 # Node ID 3ca045895945f0afc6b4d1b1868feb00382796a3 # Parent 09450ac6dc7d0f495582bf327488612755df1719 cli: add

Re: [x265] [PATCH 1 of 3] Chroma QP Offset: increase chroma QP when psy-rd is enabled

On 6/25/2014 1:22 AM, deep...@multicorewareinc.com wrote: +/* In 444, chroma gets twice as much resolution, so halve quality when psy-rd is enabled */ +if (p-internalCsp == X265_CSP_I444 p-psyRd) +{ +p-cbQpOffset += 6; +p-crQpOffset += 6; +} I dont really

Re: [x265] [PATCH 1 of 3] Chroma QP Offset: increase chroma QP when psy-rd is enabled

On 6/25/2014 3:45 PM, Deepthi Nandakumar wrote: In a sense, psy-rd encapsulates all those r-d algorithms/tweaks/hacks that improve visual quality but may hurt objective metrics like psnr/ssim. In 444, this qp hack is likely to hurt objective metrics, hence it's turned on only if psychovisual

Re: [x265] [PATCH] encoder: disable rdoq when psyrd is enabled

On 6/21/2014 2:16 AM, Deepthi Nandakumar wrote: Yes, it is. psy-rdoq is being developed, but in the meantime our tests show rdoq deteriorates quality when psy-rd is enabled. OK. - Derek ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] [PATCH] encoder: disable rdoq when psyrd is enabled

On 6/20/2014 8:00 AM, sumala...@multicorewareinc.com wrote: # HG changeset patch # User Sumalatha Polureddysumala...@multicorewareinc.com # Date 1403247577 -19800 # Node ID 3ba3a6ab5df6e140ce1c829e091dc5b2386d122d # Parent 57f26a8b7ecbf943ea54b656b2d868d51073a4db encoder: disable rdoq when

Re: [x265] Encoder::encode(): don't return 0 while flushing.

On 6/17/2014 8:03 AM, Satoshi Nakagawa wrote: using ffmpeg, when input sequence is shorter than lookahead, empty stream is encoded. Should be fixed on my (FFmpeg's) end, using something akin to what libx264 does:

Re: [x265] Problem with linking x265 and ffmpeg

On 4/22/2014 4:49 PM, 宮村 公男 wrote: $ ./configure --prefix=${TARGET} --as=yasm --enable-gpl --enable-libx265 --pkg-config-flags=—static Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Configured with:

Re: [x265] Problem with linking x265 and ffmpeg

On 4/22/2014 6:13 PM, 宮村 公男 wrote: I have 2 question. 1.Why x265.pc have line which is not need? Or in other word, why there is a line which may cause an error? I think this is a bug in x265. It shouldn't be prefixing an absolute path with '-l'. 2.Even though other third party libraries

Re: [x265] [PATCH] api: add param.bRepeatHeaders - insert stream headers in each keyframe NAL

On 3/27/2014 1:08 PM, Tim Walker wrote: FWIW, the Libav/FFmpeg wrapper already checks for return values 0 (x265.h claims x265_encoder_headers returns negative on error, even before your patch). It will continue to work even with the change, indeed. - Derek

Re: [x265] [PATCH] api: add param.bRepeatHeaders - insert stream headers in each keyframe NAL

On 3/27/2014 3:42 PM, Tim Walker wrote: It's actually broken right now because the function returns 0 on error, contrary to what the documentation says. Oh... FFFS. That'll teach me to trust documentation. - Derek ___ x265-devel mailing list

Re: [x265] [PATCH] primitives: added C primitives for upShift/downShift input pixels

On 3/12/2014 8:45 AM, Steve Borho wrote: -for (int c = 0; c width; c++) +y += lumaWidth; +Y += lumaWidth; +v += chromaWidth; +V += chromaWidth; +u += chromaWidth; +U += chromaWidth; blech. the

Re: [x265] [PATCH] param: add more validation checks

On 2/26/2014 11:01 AM, sa...@multicorewareinc.com wrote: +#define atoi(str) x265_atoi(str, bError) WTF? Why? This seems like a bad idea on many levels... - Derek ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] [PATCH] param: add more validation checks

On 2/26/2014 7:07 PM, Tim Walker wrote: x264 devs seem to think it's fine: x264 devs also think it's fine to violate the C99 spec. - Derek ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] refine MC

On 2/24/2014 9:58 AM, Satoshi Nakagawa wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1393235720 -32400 # Mon Feb 24 18:55:20 2014 +0900 # Node ID 8b5df2e11af069ceae450f20b7a637e40be9b5db # Parent 80caa9f00d7c24da67d6b24e7bf339fe74752ced refine MC An

Re: [x265] Who washed my video? x264 vs x265 'placebo' comparison

On 2/23/2014 10:22 PM, Tom Vaughan wrote: Does the MKV contain video that was ripped straight from the Blu-ray Disc? The video in the MKV is only 14 Mbps... I would have expected a higher bit rate (and more detail) if this was not re-encoded. It would be best to start with the highest quality

Re: [x265] [PATCH] rc: bug fix for encoder crash

On 2/24/2014 12:56 PM, aar...@multicorewareinc.com wrote: # HG changeset patch # User Aarthi Thirumalai # Date 1393244587 -19800 # Mon Feb 24 17:53:07 2014 +0530 # Node ID 3abef12d5b47106005c813bfd60ea49c31048f12 # Parent dce74082c20eea1f7ef9eb10f9a9addc5e7c7bb7 rc: bug fix for

Re: [x265] reduce set*SubParts()

On 2/23/2014 5:42 AM, Satoshi Nakagawa wrote: # HG changeset patch # User Satoshi Nakagawa nakagawa...@oki.com # Date 1393133917 -32400 # Sun Feb 23 14:38:37 2014 +0900 # Node ID 2f62117d39440c1d7d0360205fbdf14d6c892d9d # Parent 734f106295df911edb41b5c54e795decdcdb4f04 reduce

Re: [x265] [PATCH] Added command line options to generate a VUI and add it to the coded bitstream

On 2/19/2014 6:01 PM, dtyx...@gmail.com wrote: +bool getTilesFixedStructureFlag() { return m_tilesFixedStructureFlag; } + +void setTilesFixedStructureFlag(bool i) { m_tilesFixedStructureFlag = i; } I know this patch is pushed, but I feel it's a good time to say: This is stupid. This

[x265] Poor Development Practices

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

Re: [x265] Poor Development Practices

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

Re: [x265] Poor Development Practices

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

Re: [x265] Default GOP range: 25-250 frames or 1-10 seconds?

On 2/13/2014 1:40 PM, Mario *LigH* Rohkrämer wrote: Will you prefer a fixed number of frames as defaults for the min/max GOP length, or rather calculate the number from the framerate (rounded up, probably)? IMHO, the better idea is to calculate based on timestamps (not framerate, per se,

Re: [x265] Default GOP range: 25-250 frames or 1-10 seconds?

On 2/13/2014 8:11 PM, Steve Borho wrote: I'm missing some detail. Our default keyint min and max currently match x264's (24/250), as far as I know, and scenecut detection actually places I frames, independent of pts (also AFAIK). In x264, min is generated from the framerate:

Re: [x265] SONAME and shared lib install

On 2/12/2014 5:30 AM, i...@sina.com wrote: *Can you add parameters option like --x264opts into your patch, for that we can pass the x265's parameters from the cmd line, thanks!* Indeed if you look at the patch, I have done this. ffmpeg -i input.avi -c:v libx265 -x265-params crf=18:me=4

Re: [x265] SONAME and shared lib install

On 2/11/2014 1:05 PM, Derek Buitenhuis wrote: 1) Shared library is never install. 2) No pkg-config file is generated or installed, despite x265.pc.in existing. 3) No SONAME on the shared library. Via Anton: 4) No timestamps / way to get frame output order in the API. - Derek

Re: [x265] SONAME and shared lib install

On 2/11/2014 5:05 PM, Steve Borho wrote: re: the timestamps, the dts and pts are both in the output x265_picture returned by x265_encoder_encode() Nope. I missed that. Thanks! - Derek ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] SONAME and shared lib install

On 2/11/2014 5:16 PM, Steve Borho wrote: Am I missing something? Isn't working on Debian for me. One sec, I'll poke you on IRC. - Derek ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] Libav/FFmpeg Wrapper

On 2/10/2014 6:47 PM, Tom Vaughan wrote: Hi Derek, We have looked at this, and we have done some work for internal test frameworks. We will reach out to directly to coordinate and to support you. There's no reason this has to be private. In fact, it shouldn't be. It's writing an open source

[x265] Libav/FFmpeg Wrapper

I will be adding such a wrapper this week to both projects. But before I do, I would like to know if anyone inside MCW is already working on such a patch, to avoid duplicated effort. - Derek ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] New entropy coding - faster than Huffman, compression rate like arithmetic

On 12/30/2013 12:50 AM, Jarosław Duda wrote: I would like to propose a discussion about the possibility of applying it in video compression, maybe adding to h.265 - it should be about 10 times faster than CABAC, providing similar compression rate. This bit seems like it would perhaps be

[x265] [PATCH 0 of 2] Fix Linux Build

See topic. - Derek ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH 1 of 2] TEncSearch: Fix parameter type of xEstimateResidualQT

# HG changeset patch # User Derek Buitenhuis derek.buitenh...@gmail.com # Date 1384350763 0 # Node ID 1c8e8f6f66657bd09807707728b42689d571f881 # Parent c4ca80d19105ccf1ba2ec14dd65915f2820a660d TEncSearch: Fix parameter type of xEstimateResidualQT Fixes compilation with g++. diff -r c4ca80d19105

[x265] [PATCH 2 of 2] Reindent after last commit

# HG changeset patch # User Derek Buitenhuis derek.buitenh...@gmail.com # Date 1384350793 0 # Node ID 28475a460f963f3481f2a68626093fdd6c98ade3 # Parent 1c8e8f6f66657bd09807707728b42689d571f881 Reindent after last commit diff -r 1c8e8f6f6665 -r 28475a460f96 source/Lib/TLibEncoder/TEncSearch.cpp

Re: [x265] [PATCH 1 of 2] TEncSearch: Fix parameter type of xEstimateResidualQT

On 11/13/2013 1:55 PM, Derek Buitenhuis wrote: - UInt64rdCost, + uint64_trdCost, If you apply it, fix this indentation too. - Derek ___ x265-devel mailing list

Re: [x265] [PATCH] recon : reconstructed image write frame position calculation logic modified

On 10/23/2013 12:26 PM, Gopu Govindaswamy wrote: -ofs.seekp(pic.poc * 3 * (width * height * pixelbytes) / 2); - +uint64_t size = (pic.poc * 3); +size *= (width * height * pixelbytes); +size /= 2; +ofs.seekp(size); Why? - Derek

Re: [x265] [PATCH] recon : reconstructed image write frame position calculation logic modified

On 10/23/2013 12:33 PM, Gopu Govindaswamy wrote: (pic.poc * 3 * (width * height * pixelbytes) / 2) this statement is giving us wrong result if width and height is big So cast it properly instead of making a new stack variable? Or at the very least, explain that you are doing this to obtain

Re: [x265] [PATCH] cmake: generate and install pkgconfig file

On 10/22/2013 11:59 PM, Rafaël Carré wrote: For static linking to work, this also needs: Libs.private: -lstdc++ -lm -lpthread That only makes sense on GNU systems. - Derek ___ x265-devel mailing list x265-devel@videolan.org

Re: [x265] [PATCH] cmake: add uninstall rule for non-Windows platforms

On 10/12/2013 10:52 PM, Steve Borho wrote: # HG changeset patch # User Steve Borho st...@borho.org # Date 1381613400 18000 # Sat Oct 12 16:30:00 2013 -0500 # Node ID c18a09b9d2d3c7b249701afedd4e09cf2933312d # Parent ec98f30c518556476e1ba2acd6c79e38f3b2b137 cmake: add uninstall rule

Re: [x265] [PATCH RFC] cpu-a: remove unused safe_intel_cpu_indicator_init routine

On 10/4/2013 12:22 AM, Derek Buitenhuis wrote: Queued to test tomorrow morn. Findings: t Lib links via: /usr/bin/c++ -fPIC -fPIC -O3 -DNDEBUG -shared -Wl,-soname,libx265.so -o libx265.so CMakeFiles/x265.dir/dllmain.cpp.o common/libcommon.a encoder/libencoder.a common/vec/libPrimitivesVec.a

Re: [x265] [PATCH] common: tighten up tool descriptions; save horizontal space

On 10/1/2013 11:30 PM, Steve Borho wrote: # HG changeset patch # User Steve Borho st...@borho.org # Date 1380666567 18000 # Tue Oct 01 17:29:27 2013 -0500 # Node ID 3a4f4005d583b18215b911eb34dd5c4cd255eae4 # Parent 73f1415009ea83511469f34a9ddbf999e1c64757 common: tighten up tool

Re: [x265] [PATCH] Replace sad_12, sad_24, sad_32 vector class functions with intrinsics

On Tue, Oct 1, 2013 at 2:08 PM, dnyanesh...@multicorewareinc.com wrote: # HG changeset patch # User Dnyaneshwar # Date 1380631342 -19800 # Tue Oct 01 18:12:22 2013 +0530 # Node ID ecc483a16f1d9e0163182d090c18fad3f1616ab5 # Parent a03659cfa9574a2639292e427b2cb3d080c648ad Replace

Re: [x265] [PATCH] Accessunit: Remove unused accessUnit class

On 9/25/2013 6:58 AM, Gopu Govindaswamy wrote: # HG changeset patch # User Gopu Govindaswamy g...@multicorewareinc.com # Date 1380088686 -19800 # Node ID bb88bbe34c95b3f398a6af63c05e06a3fe7bc7d3 # Parent bdd26fd0325acf0f36409e994bdc262b11fa70f4 Accessunit: Remove unused accessUnit class

Re: [x265] [PATCH] fix hash mistake in --sao-lcu-opt=0 mode

On 9/25/2013 7:30 AM, Min Chen wrote: # HG changeset patch # User Min Chen chenm...@163.com # Date 1380090001 -28800 # Node ID 2d1646a4fc2a7aee4fba79c5c587ca396c50cbe0 # Parent 57efca19f5b8d8b5bdc22a0bb9fbfc6169724266 fix hash mistake in --sao-lcu-opt=0 mode Add how to the commit message.

Re: [x265] [PATCH 1/5][RFC] Only use UNIX line endings

On 9/24/2013 2:15 AM, Steve Borho wrote: I've pushed commits which affect these changes and go a bit further in a few cases ... Any particular reason my commits weren't used? I even sent a PR as you requested. - Derek ___ x265-devel mailing list

[x265] [PATCH 1/5][RFC] Only use UNIX line endings

Be consistent. Only use CRLF lien endings in .bat files. Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com --- build/README.txt | 136 +- build/regression/commandlines-example.txt |30 +- build/regression/config-example.txt |16 +- build

Re: [x265] [PATCH] types: use stdint.h data types for UChar, UShort, UInt64, Pel, TCoeff

On 9/19/2013 5:18 AM, Steve Borho wrote: +typedef uint8_t UChar; +typedef uint16_t UShort; +typedef unsigned int UInt; +typedef int64_t Int64; +typedef uint64_t UInt64; This seems quite wrong, since they're not necessarily analogous on all platforms... like short. Why not

Re: [x265] [PATCH 1 of 2] Always active sao-lcu-opt because we broken it after Frame Parallelism

On 9/19/2013 10:16 AM, Min Chen wrote: +// Disabled because Frame Parallelism call processRowPost early, it is broken data. +// OPT(sao-lcu-opt, param-saoLcuBasedOptimization,required_argument, 0, 0: SAO picture-based optimization, 1: SAO LCU-based optimization ) ... Why not fix it

Re: [x265] [PATCH] Resolve some patching issues for previous patch (deadlock)

On 9/17/2013 2:11 PM, Min Chen wrote: # HG changeset patch # User Min Chen chenm...@163.com # Date 1379423463 -28800 # Node ID c5c645aa14bfdbf482186730c59a000fdae10e07 # Parent 0d33ff236f68bc2238138a7213301b2efc0e6426 Resolve some patching issues for previous patch (deadlock). Can you add

Re: [x265] [PATCH]RDLevel: Disable RDOQTS when RDO and/or TS are disabled.

On Mon, Sep 16, 2013 at 7:11 AM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: # HG changeset patch # User Deepthi Nandakumar deep...@multicorewareinc.com # Date 1379311811 -19800 # Node ID c1ec5b8a6752529368753c110d626f1c53d90f3e # Parent 22c4e67c7246cd77968a86e967377e4a18b47b31

Re: [x265] [PATCH]RDLevel: Disable RDOQTS when RDO and/or TS are disabled.

On Mon, Sep 16, 2013 at 10:47 AM, Deepthi Nandakumar deep...@multicorewareinc.com wrote: Yes, this particular param flag is initialised to 1 (highest quality setting) in x265_param_default. I'm setting it to zero for a certain set of user defined parameters. What's the point of the first