[x265] How to apply the modified source codes to the library?

[hyomin.choi]

Hello all, 
I am student using x265 for my research.
I am pretty new this list, so I am not sure it is correct to ask a question in 
this mailing list.
If not, please tell me where I ask.

Basically, I am working on Mac OS X environment with X Code and trying to make 
a demo using x265 library.
I’ve check my modified source codes are working as good as my intention with 
output x265 binary in the terminal.
Then, I tried to import the library, libx265.a, but surprisingly it doesn’t 
make any change.
Even I debugged with lots of printf(“”), never make any outputs with printing 
debugging characters.

How can I actually apply the modified source code to the output library?

Best regards,
Hyomin Choi
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH] param: Disable opt-qp-pps and opt-ref-list-length-pps by default

[Pradeep Ramachandran]

# HG changeset patch
# User Pradeep Ramachandran 
# Date 1510808150 -19800
#  Thu Nov 16 10:25:50 2017 +0530
# Node ID 8b12db6c5f6bbab87887822ae9fce524e18a25c1
# Parent  dd9772385d152528201d335efbc6f75fdc43b08c
param: Disable opt-qp-pps and opt-ref-list-length-pps by default

The bits saved by these options is very miniscule, and not observable in most
tests focusing on low bitrates, and low resolutions; this was the goal of these
two options. Also, since these options change the PPS, the muxer has to ensure
that the headers are sent every frame which seems to trouble some muxers and
users.

diff -r dd9772385d15 -r 8b12db6c5f6b doc/reST/cli.rst
--- a/doc/reST/cli.rst  Tue Nov 14 11:00:09 2017 +0530
+++ b/doc/reST/cli.rst  Thu Nov 16 10:25:50 2017 +0530
@@ -2159,12 +2159,12 @@
 .. option:: --opt-qp-pps, --no-opt-qp-pps
 
Optimize QP in PPS (instead of default value of 26) based on the QP 
values
-   observed in last GOP. Default enabled.
+   observed in last GOP. Default disabled.
 
 .. option:: --opt-ref-list-length-pps, --no-opt-ref-list-length-pps
 
Optimize L0 and L1 ref list length in PPS (instead of default value of 
0)
-   based on the lengths observed in the last GOP. Default enabled.
+   based on the lengths observed in the last GOP. Default disabled.
 
 .. option:: --multi-pass-opt-rps, --no-multi-pass-opt-rps
 
diff -r dd9772385d15 -r 8b12db6c5f6b source/common/param.cpp
--- a/source/common/param.cpp   Tue Nov 14 11:00:09 2017 +0530
+++ b/source/common/param.cpp   Thu Nov 16 10:25:50 2017 +0530
@@ -271,8 +271,8 @@
 
 param->bEmitVUITimingInfo   = 1;
 param->bEmitVUIHRDInfo  = 1;
-param->bOptQpPPS= 1;
-param->bOptRefListLengthPPS = 1;
+param->bOptQpPPS= 0;
+param->bOptRefListLengthPPS = 0;
 param->bOptCUDeltaQP= 0;
 param->bAQMotion = 0;
 param->bHDROpt = 0;
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add CLI option to enable or disable picture copy to internal frame buffer

[Mario Rohkrämer]

Am 15.11.2017, 17:15 Uhr, schrieb Pradeep Ramachandran  
:



On Wed, Nov 15, 2017 at 6:52 PM, Mario *LigH* Rohkrämer 
wrote:


Am 14.11.2017, 11:11 Uhr, schrieb :

+.. option:: --copy-pic, --no-copy-pic

+
+   Allow encoder to copy input x265 pictures to internal frame
buffers. When disabled,
+   x265 will not make an internal copy of the input picture and  
will

work with the
+   application's buffers. While this allows for deeper  
integration,

it is the responsbility
+   of the application to (a) ensure that the allocated picture has
extra space for padding
+   that will be done by the library, and (b) the buffers aren't
recycled until the library
+   has completed encoding this frame (which can be figured out by
tracking NALs output by x265)
+
+   Default: enabled



I wonder how this is supposed to work with a CLI executable in a  
separate

process.

When an application integrates x265 as a DLL or linked-in library, I can
imagine that there are memory pointers to application buffers with frame
contents which can be used by the encoder.

But when calling x265 as a separate process, how does it get the frame
contents provided? Possibly as a pipe via STDIN or physical file. Means  
to

me, via file handles, allocated by the OS.

Which means of controlling any RAM frame buffers are then available to a
calling application?

In other words: Does it even make sense to expose these options to the  
CLI?


I'm curious about a usage example.



I understand the confusion this might cause. Let me try to clarify.

If you invoke the x265 application, you won't be able to access the
invoking application's memory buffers as you are in separate processes  
and
therefore this option isn't useful. This option is applicable only when  
you

do an integration of the x265 library with another application. In that
case, the option is useful because we advocate that you use the
x265_param_parse() API call to populate the right fields of the param
structure instead of directly writing the struct yourself; doing it  
through

the API ensures that all checks are done by the library. For every param,
the string that you pass to populate the param is the cli-option string  
and

therefore, exposing this as a CLI option enables folks who do deep
integration to use this option in a clean fashion

Does this make sense?


OK, so exposing it as CLI option may not help a pure x265 encoder binary  
as it is, but possibly any new application which may derive from this  
structure, especially when configuring itself with an internal CLI  
parameter string.


Vaguely understood, I hope.

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add CLI option to enable or disable picture copy to internal frame buffer

[Pradeep Ramachandran]

On Wed, Nov 15, 2017 at 6:52 PM, Mario *LigH* Rohkrämer 
wrote:

> Am 14.11.2017, 11:11 Uhr, schrieb :
>
> +.. option:: --copy-pic, --no-copy-pic
>> +
>> +   Allow encoder to copy input x265 pictures to internal frame
>> buffers. When disabled,
>> +   x265 will not make an internal copy of the input picture and will
>> work with the
>> +   application's buffers. While this allows for deeper integration,
>> it is the responsbility
>> +   of the application to (a) ensure that the allocated picture has
>> extra space for padding
>> +   that will be done by the library, and (b) the buffers aren't
>> recycled until the library
>> +   has completed encoding this frame (which can be figured out by
>> tracking NALs output by x265)
>> +
>> +   Default: enabled
>>
>
> I wonder how this is supposed to work with a CLI executable in a separate
> process.
>
> When an application integrates x265 as a DLL or linked-in library, I can
> imagine that there are memory pointers to application buffers with frame
> contents which can be used by the encoder.
>
> But when calling x265 as a separate process, how does it get the frame
> contents provided? Possibly as a pipe via STDIN or physical file. Means to
> me, via file handles, allocated by the OS.
>
> Which means of controlling any RAM frame buffers are then available to a
> calling application?
>
> In other words: Does it even make sense to expose these options to the CLI?
>
> I'm curious about a usage example.


I understand the confusion this might cause. Let me try to clarify.

If you invoke the x265 application, you won't be able to access the
invoking application's memory buffers as you are in separate processes and
therefore this option isn't useful. This option is applicable only when you
do an integration of the x265 library with another application. In that
case, the option is useful because we advocate that you use the
x265_param_parse() API call to populate the right fields of the param
structure instead of directly writing the struct yourself; doing it through
the API ensures that all checks are done by the library. For every param,
the string that you pass to populate the param is the cli-option string and
therefore, exposing this as a CLI option enables folks who do deep
integration to use this option in a clean fashion

Does this make sense?


>
>
> --
>
> Fun and success!
> Mario *LigH* Rohkrämer
> mailto:cont...@ligh.de
>
>
> ___
> x265-devel mailing list
> x265-devel@videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

Re: [x265] [PATCH] Add CLI option to enable or disable picture copy to internal frame buffer

[Mario *LigH* Rohkrämer]

Am 14.11.2017, 11:11 Uhr, schrieb :


+.. option:: --copy-pic, --no-copy-pic
+
+	Allow encoder to copy input x265 pictures to internal frame buffers.  
When disabled,
+	x265 will not make an internal copy of the input picture and will work  
with the
+	application's buffers. While this allows for deeper integration, it is  
the responsbility
+	of the application to (a) ensure that the allocated picture has extra  
space for padding
+	that will be done by the library, and (b) the buffers aren't recycled  
until the library
+	has completed encoding this frame (which can be figured out by  
tracking NALs output by x265)

+
+   Default: enabled


I wonder how this is supposed to work with a CLI executable in a separate  
process.


When an application integrates x265 as a DLL or linked-in library, I can  
imagine that there are memory pointers to application buffers with frame  
contents which can be used by the encoder.


But when calling x265 as a separate process, how does it get the frame  
contents provided? Possibly as a pipe via STDIN or physical file. Means to  
me, via file handles, allocated by the OS.


Which means of controlling any RAM frame buffers are then available to a  
calling application?


In other words: Does it even make sense to expose these options to the CLI?

I'm curious about a usage example.

--

Fun and success!
Mario *LigH* Rohkrämer
mailto:cont...@ligh.de

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

Re: [x265] [PATCH] Enable skip RD analysis intra (when sum of sub CUsplitcost bigger than non-split cost) in default param options

[Santhoshini Sekar]

Enabling splitRdSkip for Intra is not giving a bit exact output and there
is loss in compression efficiency. The reason behind this is that the
context of the entropy coder and bits are updated after all the sub CUs are
analysed whereas bEnableSplitRdSkip is terminating the analysis of the
subCUs at a much early stage.  The entropy coder can save more bits for the
sub CUs and finally the subCUs can become cheaper.

On Fri, Nov 10, 2017 at 4:11 PM,  wrote:

> # HG changeset patch
> # User Aasaipriya Chandran 
> # Date 1510220385 -19800
> #  Thu Nov 09 15:09:45 2017 +0530
> # Node ID 5f2c98ebd15e5935697c985ce856b9400d1a2ebc
> # Parent  bd438ce108435deb4f0063fca9a9e14a75e8de38
> Enable skip RD analysis intra (when sum of sub CUsplitcost bigger than
> non-split cost) in default param options
>
> diff -r bd438ce10843 -r 5f2c98ebd15e source/common/param.cpp
> --- a/source/common/param.cpp   Wed Nov 08 16:18:29 2017 +0530
> +++ b/source/common/param.cpp   Thu Nov 09 15:09:45 2017 +0530
> @@ -157,7 +157,7 @@
>  param->bEnableConstrainedIntra = 0;
>  param->bEnableStrongIntraSmoothing = 1;
>  param->bEnableFastIntra = 0;
> -param->bEnableSplitRdSkip = 0;
> +param->bEnableSplitRdSkip = 1;
>
>  /* Inter Coding tools */
>  param->searchMethod = X265_HEX_SEARCH;
> ___
> x265-devel mailing list
> x265-devel@videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel

[x265] [PATCH] API: 'x265_set_analysis_data' to capture analysis information

[praveen]

# HG changeset patch
# User Praveen Tiwari 
# Date 1510555850 -19800
#  Mon Nov 13 12:20:50 2017 +0530
# Node ID 2fec493b990ee3066e5ffc853d83669955f0ee3c
# Parent  dd9772385d152528201d335efbc6f75fdc43b08c
API: 'x265_set_analysis_data' to capture analysis information

diff -r dd9772385d15 -r 2fec493b990e doc/reST/api.rst
--- a/doc/reST/api.rst  Tue Nov 14 11:00:09 2017 +0530
+++ b/doc/reST/api.rst  Mon Nov 13 12:20:50 2017 +0530
@@ -215,6 +215,13 @@
 *the encoder will wait for this copy to complete if enabled.
 */
 
+**x265_set_analysis_data()** may be used to recive analysis information from 
external application::
+
+/* x265_set_analysis_data:
+ * set the analysis data,
+ * returns negative on error, 0 access unit were output. */
+ int x265_set_analysis_data(x265_encoder *encoder, x265_analysis_data 
*analysis_data, int poc, uint32_t cuBytes);
+
 Pictures
 
 
diff -r dd9772385d15 -r 2fec493b990e source/CMakeLists.txt
--- a/source/CMakeLists.txt Tue Nov 14 11:00:09 2017 +0530
+++ b/source/CMakeLists.txt Mon Nov 13 12:20:50 2017 +0530
@@ -29,7 +29,7 @@
 option(STATIC_LINK_CRT "Statically link C runtime for release builds" OFF)
 mark_as_advanced(FPROFILE_USE FPROFILE_GENERATE NATIVE_BUILD)
 # X265_BUILD must be incremented each time the public API is changed
-set(X265_BUILD 145)
+set(X265_BUILD 146)
 configure_file("${PROJECT_SOURCE_DIR}/x265.def.in"
"${PROJECT_BINARY_DIR}/x265.def")
 configure_file("${PROJECT_SOURCE_DIR}/x265_config.h.in"
diff -r dd9772385d15 -r 2fec493b990e source/encoder/api.cpp
--- a/source/encoder/api.cppTue Nov 14 11:00:09 2017 +0530
+++ b/source/encoder/api.cppMon Nov 13 12:20:50 2017 +0530
@@ -365,6 +365,18 @@
 return encoder->getRefFrameList((PicYuv**)l0, (PicYuv**)l1, sliceType, 
poc);
 }
 
+int x265_set_analysis_data(x265_encoder *enc, x265_analysis_data 
*analysis_data, int poc, uint32_t cuBytes)
+{
+if (!enc)
+return -1;
+
+Encoder *encoder = static_cast(enc);
+if (!encoder->setAnalysisData(analysis_data, poc, cuBytes))
+return 0;
+
+return -1;
+}
+
 void x265_cleanup(void)
 {
 BitCost::destroy();
@@ -444,6 +456,7 @@
 _csvlog_frame,
 _csvlog_encode,
 _dither_image,
+_set_analysis_data
 };
 
 typedef const x265_api* (*api_get_func)(int bitDepth);
diff -r dd9772385d15 -r 2fec493b990e source/encoder/encoder.cpp
--- a/source/encoder/encoder.cppTue Nov 14 11:00:09 2017 +0530
+++ b/source/encoder/encoder.cppMon Nov 13 12:20:50 2017 +0530
@@ -574,6 +574,88 @@
 return 0;
 }
 
+int Encoder::setAnalysisData(x265_analysis_data *analysis_data, int poc, 
uint32_t cuBytes)
+{
+uint32_t widthInCU = (m_param->sourceWidth + m_param->maxCUSize - 1) >> 
m_param->maxLog2CUSize;
+uint32_t heightInCU = (m_param->sourceHeight + m_param->maxCUSize - 1) >> 
m_param->maxLog2CUSize;
+
+Frame* curFrame = m_dpb->m_picList.getPOC(poc);
+if (curFrame != NULL)
+{
+curFrame->m_analysisData = (*analysis_data);
+curFrame->m_analysisData.numCUsInFrame = widthInCU * heightInCU;
+curFrame->m_analysisData.numPartitions = m_param->num4x4Partitions;
+allocAnalysis(>m_analysisData);
+if (m_param->maxCUSize == 16)
+{
+if (analysis_data->sliceType == X265_TYPE_IDR || 
analysis_data->sliceType == X265_TYPE_I)
+{
+curFrame->m_analysisData.sliceType = X265_TYPE_I;
+if (m_param->analysisReuseLevel < 2)
+return -1;
+
+curFrame->m_analysisData.numPartitions = 
m_param->num4x4Partitions;
+size_t count = 0;
+analysis_intra_data * currIntraData = (analysis_intra_data 
*)curFrame->m_analysisData.intraData;
+analysis_intra_data * intraData = (analysis_intra_data 
*)analysis_data->intraData;
+for (uint32_t d = 0; d < cuBytes; d++)
+{
+int bytes = curFrame->m_analysisData.numPartitions >> 
((intraData)->depth[d] * 2);
+memset(&(currIntraData)->depth[count], 
(intraData)->depth[d], bytes);
+memset(&(currIntraData)->chromaModes[count], 
(intraData)->chromaModes[d], bytes);
+memset(&(currIntraData)->partSizes[count], 
(intraData)->partSizes[d], bytes);
+memset(&(currIntraData)->partSizes[count], 
(intraData)->partSizes[d], bytes);
+count += bytes;
+}
+memcpy(&(currIntraData)->modes, (intraData)->modes, 
curFrame->m_analysisData.numPartitions * analysis_data->numCUsInFrame);
+}
+else
+{
+uint32_t numDir = analysis_data->sliceType == X265_TYPE_P ? 1 
: 2;
+if (m_param->analysisReuseLevel < 2)
+return -1;
+
+curFrame->m_analysisData.numPartitions =