[x265] [PATCH] Add dynamic rate-control reconfiguration

[aruna]

# HG changeset patch
# User Aruna Matheswaran 
# Date 1487757265 -19800
#  Wed Feb 22 15:24:25 2017 +0530
# Node ID 3c26e29120aa0a383e09a1c9eee2d803792d0180
# Parent  08a05ca9fd16c9f5efb1ce4d8389bda8a63f5f7d
Add dynamic rate-control reconfiguration

diff -r 08a05ca9fd16 -r 3c26e29120aa source/common/frame.cpp
--- a/source/common/frame.cpp   Mon Mar 27 12:35:20 2017 +0530
+++ b/source/common/frame.cpp   Wed Feb 22 15:24:25 2017 +0530
@@ -47,6 +47,7 @@
 memset(_lowres, 0, sizeof(m_lowres));
 m_rcData = NULL;
 m_encodeStartTime = 0;
+m_reconfigureRc = false;
 }
 
 bool Frame::create(x265_param *param, float* quantOffsets)
diff -r 08a05ca9fd16 -r 3c26e29120aa source/common/frame.h
--- a/source/common/frame.h Mon Mar 27 12:35:20 2017 +0530
+++ b/source/common/frame.h Wed Feb 22 15:24:25 2017 +0530
@@ -84,6 +84,7 @@
 Lowres m_lowres;
 bool   m_lowresInit; // lowres init complete 
(pre-analysis)
 bool   m_bChromaExtended;// orig chroma planes motion 
extended for weight analysis
+bool   m_reconfigureRc;
 
 float* m_quantOffsets;   // points to quantOffsets in 
x265_picture
 x265_sei   m_userSEI;
diff -r 08a05ca9fd16 -r 3c26e29120aa source/encoder/api.cpp
--- a/source/encoder/api.cppMon Mar 27 12:35:20 2017 +0530
+++ b/source/encoder/api.cppWed Feb 22 15:24:25 2017 +0530
@@ -171,7 +171,7 @@
 
 x265_param save;
 Encoder* encoder = static_cast(enc);
-if (encoder->m_reconfigure) /* Reconfigure in progress */
+if (encoder->m_reconfigure || encoder->m_reconfigureRc) /* Reconfigure in 
progress */
 return 1;
 memcpy(, encoder->m_latestParam, sizeof(x265_param));
 int ret = encoder->reconfigureParam(encoder->m_latestParam, param_in);
@@ -197,7 +197,22 @@
 return -1;
 }
 }
-encoder->m_reconfigure = true;
+if (encoder->m_reconfigureRc)
+{
+VPS saveVPS;
+memcpy(, >m_vps.ptl, sizeof(saveVPS.ptl));
+determineLevel(*encoder->m_latestParam, encoder->m_vps);
+if (saveVPS.ptl.profileIdc != encoder->m_vps.ptl.profileIdc || 
saveVPS.ptl.levelIdc != encoder->m_vps.ptl.levelIdc
+|| saveVPS.ptl.tierFlag != encoder->m_vps.ptl.tierFlag)
+{
+x265_log(encoder->m_param, X265_LOG_WARNING, 
"Profile/Level/Tier has changed from %d/%d/%s to %d/%d/%s.Cannot reconfigure 
rate-control.\n",
+ saveVPS.ptl.profileIdc, saveVPS.ptl.levelIdc, 
saveVPS.ptl.tierFlag ? "High" : "Main", encoder->m_vps.ptl.profileIdc,
+ encoder->m_vps.ptl.levelIdc, 
encoder->m_vps.ptl.tierFlag ? "High" : "Main");
+encoder->m_reconfigureRc = false;
+}
+}
+else
+encoder->m_reconfigure = true;
 encoder->printReconfigureParams();
 }
 return ret;
diff -r 08a05ca9fd16 -r 3c26e29120aa source/encoder/encoder.cpp
--- a/source/encoder/encoder.cppMon Mar 27 12:35:20 2017 +0530
+++ b/source/encoder/encoder.cppWed Feb 22 15:24:25 2017 +0530
@@ -56,6 +56,7 @@
 {
 m_aborted = false;
 m_reconfigure = false;
+m_reconfigureRc = false;
 m_encodedFrameNum = 0;
 m_pocLast = -1;
 m_curEncoder = 0;
@@ -607,7 +608,7 @@
 {
 inFrame = new Frame;
 inFrame->m_encodeStartTime = x265_mdate();
-x265_param* p = m_reconfigure ? m_latestParam : m_param;
+x265_param* p = (m_reconfigure || m_reconfigureRc) ? m_latestParam 
: m_param;
 if (inFrame->create(p, pic_in->quantOffsets))
 {
 /* the first PicYuv created is asked to generate the CU and 
block unit offset
@@ -674,7 +675,7 @@
 inFrame->m_userData  = pic_in->userData;
 inFrame->m_pts   = pic_in->pts;
 inFrame->m_forceqp   = pic_in->forceqp;
-inFrame->m_param = m_reconfigure ? m_latestParam : m_param;
+inFrame->m_param = (m_reconfigure || m_reconfigureRc) ? 
m_latestParam : m_param;
 
 if (pic_in->userSEI.numPayloads)
 {
@@ -740,6 +741,8 @@
 inFrame->m_lowres.bScenecut = !!inFrame->m_analysisData.bScenecut;
 inFrame->m_lowres.satdCost = inFrame->m_analysisData.satdCost;
 }
+if (m_reconfigureRc)
+inFrame->m_reconfigureRc = true;
 
 m_lookahead->addPicture(*inFrame, sliceType);
 m_numDelayedPic++;
@@ -940,6 +943,15 @@
 if (m_param->rc.bStatRead)
 readAnalysis2PassFile(>m_analysis2Pass, 
frameEnc->m_poc, frameEnc->m_lowres.sliceType);
  }
+
+if (frameEnc->m_reconfigureRc && m_reconfigureRc)
+{
+memcpy(m_param, m_latestParam, sizeof(x265_param));
+m_rateControl->reconfigureRC();
+   

Re: [x265] [PATCH] Add dynamic rate-control reconfiguration

[Aruna Matheswaran]

On Thu, Apr 6, 2017 at 1:35 PM, Aarthi Priya Thirumalai <
aar...@multicorewareinc.com> wrote:

>
>
> On Tue, Apr 4, 2017 at 6:34 PM,  wrote:
>
>> # HG changeset patch
>> # User Aruna Matheswaran 
>> # Date 1487757265 -19800
>> #  Wed Feb 22 15:24:25 2017 +0530
>> # Node ID 576ad673d9b352c45853b7ffeeacce7d23268bb8
>> # Parent  08a05ca9fd16c9f5efb1ce4d8389bda8a63f5f7d
>> Add dynamic rate-control reconfiguration
>>
>> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/common/frame.cpp
>> --- a/source/common/frame.cpp   Mon Mar 27 12:35:20 2017 +0530
>> +++ b/source/common/frame.cpp   Wed Feb 22 15:24:25 2017 +0530
>> @@ -47,6 +47,7 @@
>>  memset(_lowres, 0, sizeof(m_lowres));
>>  m_rcData = NULL;
>>  m_encodeStartTime = 0;
>> +m_reconfigureRc = false;
>>  }
>>
>>  bool Frame::create(x265_param *param, float* quantOffsets)
>> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/common/frame.h
>> --- a/source/common/frame.h Mon Mar 27 12:35:20 2017 +0530
>> +++ b/source/common/frame.h Wed Feb 22 15:24:25 2017 +0530
>> @@ -84,6 +84,7 @@
>>  Lowres m_lowres;
>>  bool   m_lowresInit; // lowres init complete
>> (pre-analysis)
>>  bool   m_bChromaExtended;// orig chroma planes
>> motion extended for weight analysis
>> +bool   m_reconfigureRc;
>>
>>  float* m_quantOffsets;   // points to
>> quantOffsets in x265_picture
>>  x265_sei   m_userSEI;
>> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/encoder/api.cpp
>> --- a/source/encoder/api.cppMon Mar 27 12:35:20 2017 +0530
>> +++ b/source/encoder/api.cppWed Feb 22 15:24:25 2017 +0530
>> @@ -171,7 +171,7 @@
>>
>>  x265_param save;
>>  Encoder* encoder = static_cast(enc);
>> -if (encoder->m_reconfigure) /* Reconfigure in progress */
>> +if (encoder->m_reconfigure || encoder->m_reconfigureRc) /*
>> Reconfigure in progress */
>>  return 1;
>>  memcpy(, encoder->m_latestParam, sizeof(x265_param));
>>  int ret = encoder->reconfigureParam(encoder->m_latestParam,
>> param_in);
>> @@ -197,7 +197,22 @@
>>  return -1;
>>  }
>>  }
>> -encoder->m_reconfigure = true;
>> +if (encoder->m_reconfigureRc)
>> +{
>> +VPS saveVPS;
>> +memcpy(, >m_vps.ptl,
>> sizeof(saveVPS.ptl));
>> +determineLevel(*encoder->m_latestParam, encoder->m_vps);
>> +if (saveVPS.ptl.profileIdc != encoder->m_vps.ptl.profileIdc
>> || saveVPS.ptl.levelIdc != encoder->m_vps.ptl.levelIdc
>> +|| saveVPS.ptl.tierFlag != encoder->m_vps.ptl.tierFlag)
>> +{
>> +x265_log(encoder->m_param, X265_LOG_WARNING,
>> "Profile/Level/Tier has changed from %d/%d/%s to %d/%d/%s.Cannot
>> reconfigure rate-control.\n",
>> + saveVPS.ptl.profileIdc, saveVPS.ptl.levelIdc,
>> saveVPS.ptl.tierFlag ? "High" : "Main", encoder->m_vps.ptl.profileIdc,
>> + encoder->m_vps.ptl.levelIdc,
>> encoder->m_vps.ptl.tierFlag ? "High" : "Main");
>> +encoder->m_reconfigureRc = false;
>> +}
>> +}
>> +else
>> +encoder->m_reconfigure = true;
>>
> why set only m_reconfigure as true,  where are you setting m_reconfigureRc
> to true?
>

m_reconfigureRc will get set to true inside reconfigureParam().


>  encoder->printReconfigureParams();
>>  }
>>  return ret;
>> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/encoder/encoder.cpp
>> --- a/source/encoder/encoder.cppMon Mar 27 12:35:20 2017 +0530
>> +++ b/source/encoder/encoder.cppWed Feb 22 15:24:25 2017 +0530
>> @@ -56,6 +56,7 @@
>>  {
>>  m_aborted = false;
>>  m_reconfigure = false;
>> +m_reconfigureRc = false;
>>  m_encodedFrameNum = 0;
>>  m_pocLast = -1;
>>  m_curEncoder = 0;
>> @@ -607,7 +608,7 @@
>>  {
>>  inFrame = new Frame;
>>  inFrame->m_encodeStartTime = x265_mdate();
>> -x265_param* p = m_reconfigure ? m_latestParam : m_param;
>>
> no need for this change - when reconfigureRc is true, m_reconfigure will
> also be true..so dont need to change these
>

Both m_reconfigure and m_reconfigureRc will not be true at a
time.m_reconfigureRc will be set true when rate-control parameters have to
be reconfigured and it will show effect from the next pic_in. For all other
parameters m_reconfigure will be set true and it will show effect from the
next frame to be encoded.


+x265_param* p = (m_reconfigure || m_reconfigureRc) ?
>> m_latestParam : m_param;
>>  if (inFrame->create(p, pic_in->quantOffsets))
>>  {
>>  /* the first PicYuv created is asked to generate the CU
>> and block unit offset
>> @@ -674,7 +675,7 @@
>>  inFrame->m_userData  = pic_in->userData;
>>  

Re: [x265] [PATCH] Add dynamic rate-control reconfiguration

[Aarthi Priya Thirumalai]

On Tue, Apr 4, 2017 at 6:34 PM,  wrote:

> # HG changeset patch
> # User Aruna Matheswaran 
> # Date 1487757265 -19800
> #  Wed Feb 22 15:24:25 2017 +0530
> # Node ID 576ad673d9b352c45853b7ffeeacce7d23268bb8
> # Parent  08a05ca9fd16c9f5efb1ce4d8389bda8a63f5f7d
> Add dynamic rate-control reconfiguration
>
> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/common/frame.cpp
> --- a/source/common/frame.cpp   Mon Mar 27 12:35:20 2017 +0530
> +++ b/source/common/frame.cpp   Wed Feb 22 15:24:25 2017 +0530
> @@ -47,6 +47,7 @@
>  memset(_lowres, 0, sizeof(m_lowres));
>  m_rcData = NULL;
>  m_encodeStartTime = 0;
> +m_reconfigureRc = false;
>  }
>
>  bool Frame::create(x265_param *param, float* quantOffsets)
> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/common/frame.h
> --- a/source/common/frame.h Mon Mar 27 12:35:20 2017 +0530
> +++ b/source/common/frame.h Wed Feb 22 15:24:25 2017 +0530
> @@ -84,6 +84,7 @@
>  Lowres m_lowres;
>  bool   m_lowresInit; // lowres init complete
> (pre-analysis)
>  bool   m_bChromaExtended;// orig chroma planes
> motion extended for weight analysis
> +bool   m_reconfigureRc;
>
>  float* m_quantOffsets;   // points to
> quantOffsets in x265_picture
>  x265_sei   m_userSEI;
> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/encoder/api.cpp
> --- a/source/encoder/api.cppMon Mar 27 12:35:20 2017 +0530
> +++ b/source/encoder/api.cppWed Feb 22 15:24:25 2017 +0530
> @@ -171,7 +171,7 @@
>
>  x265_param save;
>  Encoder* encoder = static_cast(enc);
> -if (encoder->m_reconfigure) /* Reconfigure in progress */
> +if (encoder->m_reconfigure || encoder->m_reconfigureRc) /*
> Reconfigure in progress */
>  return 1;
>  memcpy(, encoder->m_latestParam, sizeof(x265_param));
>  int ret = encoder->reconfigureParam(encoder->m_latestParam,
> param_in);
> @@ -197,7 +197,22 @@
>  return -1;
>  }
>  }
> -encoder->m_reconfigure = true;
> +if (encoder->m_reconfigureRc)
> +{
> +VPS saveVPS;
> +memcpy(, >m_vps.ptl,
> sizeof(saveVPS.ptl));
> +determineLevel(*encoder->m_latestParam, encoder->m_vps);
> +if (saveVPS.ptl.profileIdc != encoder->m_vps.ptl.profileIdc
> || saveVPS.ptl.levelIdc != encoder->m_vps.ptl.levelIdc
> +|| saveVPS.ptl.tierFlag != encoder->m_vps.ptl.tierFlag)
> +{
> +x265_log(encoder->m_param, X265_LOG_WARNING,
> "Profile/Level/Tier has changed from %d/%d/%s to %d/%d/%s.Cannot
> reconfigure rate-control.\n",
> + saveVPS.ptl.profileIdc, saveVPS.ptl.levelIdc,
> saveVPS.ptl.tierFlag ? "High" : "Main", encoder->m_vps.ptl.profileIdc,
> + encoder->m_vps.ptl.levelIdc,
> encoder->m_vps.ptl.tierFlag ? "High" : "Main");
> +encoder->m_reconfigureRc = false;
> +}
> +}
> +else
> +encoder->m_reconfigure = true;
>
why set only m_reconfigure as true,  where are you setting m_reconfigureRc
to true?

>  encoder->printReconfigureParams();
>  }
>  return ret;
> diff -r 08a05ca9fd16 -r 576ad673d9b3 source/encoder/encoder.cpp
> --- a/source/encoder/encoder.cppMon Mar 27 12:35:20 2017 +0530
> +++ b/source/encoder/encoder.cppWed Feb 22 15:24:25 2017 +0530
> @@ -56,6 +56,7 @@
>  {
>  m_aborted = false;
>  m_reconfigure = false;
> +m_reconfigureRc = false;
>  m_encodedFrameNum = 0;
>  m_pocLast = -1;
>  m_curEncoder = 0;
> @@ -607,7 +608,7 @@
>  {
>  inFrame = new Frame;
>  inFrame->m_encodeStartTime = x265_mdate();
> -x265_param* p = m_reconfigure ? m_latestParam : m_param;
>
no need for this change - when reconfigureRc is true, m_reconfigure will
also be true..so dont need to change these

> +x265_param* p = (m_reconfigure || m_reconfigureRc) ?
> m_latestParam : m_param;
>  if (inFrame->create(p, pic_in->quantOffsets))
>  {
>  /* the first PicYuv created is asked to generate the CU
> and block unit offset
> @@ -674,7 +675,7 @@
>  inFrame->m_userData  = pic_in->userData;
>  inFrame->m_pts   = pic_in->pts;
>  inFrame->m_forceqp   = pic_in->forceqp;
> -inFrame->m_param = m_reconfigure ? m_latestParam : m_param;
>
same as above. for any reconfigure, set m_reconfigure to true,
additionally, set m_reconfigureRc to true for
Rate control reconfigure changes. no need for the above change then

> +inFrame->m_param = (m_reconfigure || m_reconfigureRc) ?
> m_latestParam : m_param;
>
>  if (pic_in->userSEI.numPayloads)
>  {
> @@ -740,6 +741,8 @@
>  inFrame->m_lowres.bScenecut = !!inFrame->m_analysisData.
> 

Re: [x265] memory consumption when encoding 8K video

[Mario *LigH* Rohkrämer]

Already FullHD (1080p) can be tricky with a 32-bit build.

4K UHD works on a PC with 8 GB RAM, but 8K UHD may allocate around 12 GB,  
so I experienced heavy swapping.



Am 06.04.2017, 07:18 Uhr, schrieb Santhoshini Sekar  
:



Hi Yiran Li,

We found such memory issues for 32-bit builds even with 4K content. It is
very natural for a 32 bit build to fail for high resolution videos. We  
have

a bitbucket issue pointing to this (
https://bitbucket.org/multicoreware/x265/issues/310/memory-error-crash-in-32-bit-compiler-for
).

Thanks,
Santhoshini

On Thu, Apr 6, 2017 at 9:42 AM, YIRAN LI  wrote:


Hi Pradeep,

I'm now using x265.exe to reproduce this issue and yes I was able to
reproduce it.

The thing is, x265.exe only accepts .yuv or y4m which store uncompressed
data so even only 1 second long clip takes more than 1 GB so I can't  
upload

them.

If you want, you can use MSPaint to create a 8K jpg, then use ffmpeg
command to create a 1 second clip, here is the command line:
* ffmpeg.exe -framerate 30 -loop 1 -i  
0001.jpg

-t 1 -pix_fmt yuv420p a.y4m*

Once created, you can use x265.exe to convert it:


$ x265.exe --input a.y4m -o a.mp4

y4m  [info]: 8192x4096 fps 30/1 i420p8 sar 1:1 frames 0 - 29 of 30

raw  [info]: output file: a.mp4

x265 [info]: HEVC encoder version 2.3

x265 [info]: build info [Windows][GCC 5.4.0][32 bit] 8bit

x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2
FMA3 LZCNT BMI2

x265 [info]: Main profile, Level-6 (Main tier)

x265 [info]: Thread pool created using 4 threads

x265 [info]: Slices  : 1

x265 [info]: frame threads / pool features   : 2 / wpp(64 rows)

x265 [info]: Coding QT: max CU size, min CU size : 64 / 8

x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1  
intra


x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2

x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00

x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2

x265 [info]: b-pyramid / weightp / weightb   : 1 / 1 / 0

x265 [info]: References / ref-limit  cu / depth  : 3 / on / on

x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1

x265 [info]: Rate Control / qCompress: CRF-28.0 / 0.60

x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp
strong-intra-smoothing

x265 [info]: tools: lslices=8 deblock sao

x265 [error]: malloc of size 37871616 failed

x265 [error]: memory allocation failure, aborting encode


encoded 0 frames

aborted at input frame 15, output frame 0

​I've tried almost all possible options:

*x265.exe --input ​a.y4m -F 1 --lookahead-threads 1 --rc-lookahead 0
--bframes 0 --no-b-pyramid --ref 1 -o a.mp4*

I
​'m not familiar with ​these parameters, could you tell me what possible
problems/disadvantages will the generated file have by
setting ref = 1, bframe = 0?

Great thanks

2017-04-06 13:35 GMT+10:00 Pradeep Ramachandran <
prad...@multicorewareinc.com>:

In general, I would recommend against a 32-bit build due to the fact  
that
several of our assembly optimizations (10-bit and 12-bit, in  
particular)
work only for 64-bit which would considerably restrict your encoding  
speed.
This is especially true for 8K where there is so many bits to deal  
with!


If you can share with us the command-line that you are trying, along  
with

a sample clip, we can try to reproduce the failure from our side.

Pradeep Ramachandran, PhD
Solution Architect at www.multicorewareinc.com/
Adjunct Faculty at www.cse.iitm.ac.in/
pradeeprama.info/
Ph:   +91 99627 82018 <+91%2099627%2082018>

On Thu, Apr 6, 2017 at 6:22 AM, YIRAN LI  wrote:


Hi guys,

I'm writing a program which can encode video using X265 API.  It's a  
32

bit program.

When the program runs to encode a 8K video, I can see every
time encoder_encode is called, the program eats about 100MB so that  
after

12 frames are sent to encoder and when encoder_encode  is called for
another frame,  encoder_encode  returns failure. (at this time, about  
1.5GB

in total is consumed by the encoder).


I guess it's caused by memory limit so compiled everything to 64bit,
this time everything went well and I could see maximum memory  
consumption

is about 6GB.


But I still need to fix the problem on 32bit because a lot of  
customers
use 32 bit version. Just want to know, is there any option, to make  
encoder
hold less frames or what ever option that can make encoder consume  
less

memory?


Thanks for suggestion.



___
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-devel mailing list

Re: [x265] memory consumption when encoding 8K video

[Michael Lackner]

I'm also working with 8K content at the moment, and my goal was mostly to push 
it below
16GiB of memory consumption. When working with that, I found out that there are 
some
things you can do to reduce memory consumption:

1.) Reduce B-Frames ('--bframes 0'), lowering efficiency
2.) Reduce chroma subsampling (If you're on YUV 4:4:4 or YUV 4:2:2, go for 
4:2:0 instead)
3.) Reduce bits per color channel (probably no applicable for your 32-bit 
build, but 8-bit
consumes slightly less than 10-/12-bit. Only relevant if you have a patched 
build that
allows for deep color on 32-bit, '-D 8')
3.) Reduce threads!

When it comes to threads, it's best to just throw parallelization away 
entirely, consuming
much less RAM, but also being much slower on multicore machines:

-F 0 --lookahead-threads 0 --slices 1 --lookahead-slices 0 --no-wpp --no-pmode 
--no-pme

Additionally, you might wish to limit the CU sizes to larger blocks, which 
*might* (I
haven't tested this) save memory at the cost of quality in detailed parts of 
frames:

--ctu 64 --min-cu-size 32

(This might be really bad advice though, quality-wise, not sure...)

While I haven't tested this extensively, I managed to reduce memory from around 
~30GiB to
~14GiB by just going from YUV 4:4:4 and 12-bit input to YUV 4:2:0 and 10-bit 
input as well
as a reduction of B-Frames from 16 to 4 at 12 logical CPUs. Initial consumption 
was around
~32GiB with 32 logical CPUs (more threads!). The chroma subsampling had the 
biggest impact
though.

It's all laymans' advice from my side, but maybe parts of this can help you.

On 04/06/2017 02:52 AM, YIRAN LI wrote:
> Hi guys,
> 
> I'm writing a program which can encode video using X265 API.  It's a 32 bit
> program.
> 
> When the program runs to encode a 8K video, I can see every
> time encoder_encode is called, the program eats about 100MB so that after
> 12 frames are sent to encoder and when encoder_encode  is called for
> another frame,  encoder_encode  returns failure. (at this time, about 1.5GB
> in total is consumed by the encoder).
> 
> 
> I guess it's caused by memory limit so compiled everything to 64bit, this
> time everything went well and I could see maximum memory consumption is
> about 6GB.
> 
> 
> But I still need to fix the problem on 32bit because a lot of customers use
> 32 bit version. Just want to know, is there any option, to make encoder
> hold less frames or what ever option that can make encoder consume less
> memory?
> 
> 
> Thanks for suggestion.

-- 
Michael Lackner
Lehrstuhl für Informationstechnologie (CiT)
Montanuniversität Leoben
Tel.: +43 (0)3842/402-1505 | Mail: michael.lack...@unileoben.ac.at
Fax.: +43 (0)3842/402-1502 | Web: http://institute.unileoben.ac.at/infotech
___
x265-devel mailing list
x265-devel@videolan.org
https://mailman.videolan.org/listinfo/x265-devel