[x265] x265 CPU utilization very low on a multi-numa sockets server

Discussion:

Ximing Cheng

2015-07-28 01:58:08 UTC

Hi, I am testing x265 with a two numa nodes server, each node has 36 cores.
The x265 version is 1.7 release with command line

./x265 --input-res 1920x1080 --input input.yuv --bitrate 1200 --vbv-maxrate
1380 --fps 20 --early-skip --preset fast -o test1.hevc

but when ruuning on the server, CPU utilization ranges from 27% ~ 35% (<
40%) which means most of the CPU cores are not busy.

x265 [info]: HEVC encoder version 1.7x265 [info]: build info
[Linux][GCC 4.4.6][64 bit] 8bppx265 [info]: using cpu capabilities:
MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2x265 [warning]:
--psnr used with AQ on: results will be invalid!x265 [warning]: --tune
psnr should be used if attempting to benchmark psnr!x265 [info]: Main
profile, Level-4 (Main tier)x265 [info]: Thread pool 0 using 36
threads on NUMA node 0x265 [info]: Thread pool 1 using 36 threads on
NUMA node 1x265 [info]: frame threads / pool features : 16 /
wpp(34 rows)+pmodex265 [warning]: VBV maxrate specified, but no
bufsize, ignoredx265 [info]: Coding QT: max CU size, min CU size : 32
/ 8x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intrax265 [info]: ME / range / subpel / merge : star / 57 / 1
/ 2x265 [info]: Keyframe min / max / scenecut : 20 / 250 /
40x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2x265
[info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1x265
[info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.3 / 32 / 1x265
[info]: Rate Control / qCompress : ABR-1200 kbps / 0.60x265
[info]: tools: rect amp rd=4 rdoq=2 early-skip signhide tmvp b-intra

Pradeep Ramachandran

2015-07-28 05:46:47 UTC

Permalink

Ximing Cheng,
To increase CPU utilization, you will have to run a higher resolution video
(targeting a higher bit rate) in a more advanced setting for a longer
duration - a 20 frames of 1080p video encoded with a target bit rate of
1200 in 'fast' preset may not be sufficient to fill out 72 contexts. With
higher resolution videos we do see that heavily threaded machines get
decent utilization; doesn't hit a 100% all the time but it is better than
35%.

Also, I can try reproducing your result if you can you give your complete
command line - the console output shows that some of the default settings
have been altered (like frame threads) but your command line doesn't list
them.

Thanks,
Pradeep.

Post by Ximing Cheng
Hi, I am testing x265 with a two numa nodes server, each node has 36
cores. The x265 version is 1.7 release with command line
./x265 --input-res 1920x1080 --input input.yuv --bitrate 1200
--vbv-maxrate 1380 --fps 20 --early-skip --preset fast -o test1.hevc
but when ruuning on the server, CPU utilization ranges from 27% ~ 35% (<
40%) which means most of the CPU cores are not busy.
x265 [info]: HEVC encoder version 1.7x265 [info]: build info [Linux][GCC 4.4.6][64 bit] 8bppx265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2x265 [warning]: --psnr used with AQ on: results will be invalid!x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!x265 [info]: Main profile, Level-4 (Main tier)x265 [info]: Thread pool 0 using 36 threads on NUMA node 0x265 [info]: Thread pool 1 using 36 threads on NUMA node 1x265 [info]: frame threads / pool features : 16 / wpp(34 rows)+pmodex265 [warning]: VBV maxrate specified, but no bufsize, ignoredx265 [info]: Coding QT: max CU size, min CU size : 32 / 8x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intrax265 [info]: ME / range / subpel / merge : star / 57 / 1 / 2x265 [info]: Keyframe min / max / scenecut : 20 / 250 / 40x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.3 / 32 / 1x265 [info]: Rate Control / qCompress : ABR-1200 kbps / 0.60x265 [info]: tools: rect amp rd=4 rdoq=2 early-skip signhide tmvp b-intra
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

Pradeep Ramachandran

2015-07-28 05:55:22 UTC

Permalink

My bad in reading the command line - 20 is the fps of the video, and not
the # frames to encode. Ignore that part of the comment above.
Pradeep.

On Tue, Jul 28, 2015 at 11:16 AM, Pradeep Ramachandran <

Post by Pradeep Ramachandran
Ximing Cheng,
To increase CPU utilization, you will have to run a higher resolution
video (targeting a higher bit rate) in a more advanced setting for a longer
duration - a 20 frames of 1080p video encoded with a target bit rate of
1200 in 'fast' preset may not be sufficient to fill out 72 contexts. With
higher resolution videos we do see that heavily threaded machines get
decent utilization; doesn't hit a 100% all the time but it is better than
35%.
Also, I can try reproducing your result if you can you give your complete
command line - the console output shows that some of the default settings
have been altered (like frame threads) but your command line doesn't list
them.
Thanks,
Pradeep.

Mario *LigH* Rohkrämer

2015-07-28 05:57:30 UTC

Permalink

Hi Cheng.

This issue has been discussed before in the VideoHelp forum.
Parallelization is a bit more limited because dependencies between tasks
in HEVC algorithms are possibly more restrictive than in AVC algorithms
(many parts of the HEVC algorithm need to wait for others finishing
intermediate results, and splitting the video frame across too many slices
would hurt the encoding efficiency).

But it is easily possible to run several applications in parallel so that
they each get a share of available cores.

Post by Ximing Cheng
Hi, I am testing x265 with a two numa nodes server, each node has 36 cores.
The x265 version is 1.7 release with command line
./x265 --input-res 1920x1080 --input input.yuv --bitrate 1200
--vbv-maxrate
1380 --fps 20 --early-skip --preset fast -o test1.hevc
but when ruuning on the server, CPU utilization ranges from 27% ~ 35% (<
40%) which means most of the CPU cores are not busy.
x265 [info]: HEVC encoder version 1.7x265 [info]: build info
--psnr used with AQ on: results will be invalid!x265 [warning]: --tune
psnr should be used if attempting to benchmark psnr!x265 [info]: Main
profile, Level-4 (Main tier)x265 [info]: Thread pool 0 using 36
threads on NUMA node 0x265 [info]: Thread pool 1 using 36 threads on
NUMA node 1x265 [info]: frame threads / pool features : 16 /
wpp(34 rows)+pmodex265 [warning]: VBV maxrate specified, but no
bufsize, ignoredx265 [info]: Coding QT: max CU size, min CU size : 32
/ 8x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intrax265 [info]: ME / range / subpel / merge : star / 57 / 1
/ 2x265 [info]: Keyframe min / max / scenecut : 20 / 250 /
40x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2x265
[info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1x265
[info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.3 / 32 / 1x265
[info]: Rate Control / qCompress : ABR-1200 kbps / 0.60x265
[info]: tools: rect amp rd=4 rdoq=2 early-skip signhide tmvp b-intra

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

Ximing Cheng

2015-08-03 02:12:04 UTC

Permalink

I found the lookahead JobProvider only process its tasks on the threadpool
zero (the first threadpool), this will destroy the load balance of the
muti-threadpool system as the frame encoders are distributed on
the muti-threadpool by round robin. The encoder could not fully use the CPU
resource as the HEVC algorithm's high correlation.
Some of the worker thread sometimes waiting for the Job to awaken them, but
lookahead could not awaken thread on the second threadpool. And the main
x265 encoder must wait for the output queue of the lookahead. If the
lookahead use the same round robin strategy to distribute different frames
on the muti-threadpool as the frame encoder, is it better for the muti-numa
system? Thanks!

Post by Mario *LigH* RohkrÃ¤mer
Hi Cheng.
This issue has been discussed before in the VideoHelp forum.
Parallelization is a bit more limited because dependencies between tasks in
HEVC algorithms are possibly more restrictive than in AVC algorithms (many
parts of the HEVC algorithm need to wait for others finishing intermediate
results, and splitting the video frame across too many slices would hurt
the encoding efficiency).
But it is easily possible to run several applications in parallel so that
they each get a share of available cores.
Hi, I am testing x265 with a two numa nodes server, each node has 36 cores.

Post by Ximing Cheng
The x265 version is 1.7 release with command line
./x265 --input-res 1920x1080 --input input.yuv --bitrate 1200
--vbv-maxrate
1380 --fps 20 --early-skip --preset fast -o test1.hevc
but when ruuning on the server, CPU utilization ranges from 27% ~ 35% (<
40%) which means most of the CPU cores are not busy.
x265 [info]: HEVC encoder version 1.7x265 [info]: build info
--psnr used with AQ on: results will be invalid!x265 [warning]: --tune
psnr should be used if attempting to benchmark psnr!x265 [info]: Main
profile, Level-4 (Main tier)x265 [info]: Thread pool 0 using 36
threads on NUMA node 0x265 [info]: Thread pool 1 using 36 threads on
NUMA node 1x265 [info]: frame threads / pool features : 16 /
wpp(34 rows)+pmodex265 [warning]: VBV maxrate specified, but no
bufsize, ignoredx265 [info]: Coding QT: max CU size, min CU size : 32
/ 8x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intrax265 [info]: ME / range / subpel / merge : star / 57 / 1
/ 2x265 [info]: Keyframe min / max / scenecut : 20 / 250 /
40x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2x265
[info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1x265
[info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.3 / 32 / 1x265
[info]: Rate Control / qCompress : ABR-1200 kbps / 0.60x265
[info]: tools: rect amp rd=4 rdoq=2 early-skip signhide tmvp b-intra

--
Fun and success!
Mario *LigH* RohkrÃ€mer
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

Deepthi Nandakumar

2015-08-03 04:09:51 UTC

Permalink

Hello,

Scheduling the lookahead thread to threadpool using round robin allocation
has been on the task list for some time, but it's doubtful how much extra
performance it would fetch (there's a case to be made for odd count frame
encoders, though). Are you using -F16 - that sounds way too high for any
real performance benefits.

We're working on some more numa optimizations, specifically forcing recon
and reference frame allocation onto specific nodes.

Thanks,
Deepthi

Post by Ximing Cheng
I found the lookahead JobProvider only process its tasks on the threadpool
zero (the first threadpool), this will destroy the load balance of the
muti-threadpool system as the frame encoders are distributed on
the muti-threadpool by round robin. The encoder could not fully use the CPU
resource as the HEVC algorithm's high correlation.
Some of the worker thread sometimes waiting for the Job to awaken them,
but lookahead could not awaken thread on the second threadpool. And the
main x265 encoder must wait for the output queue of the lookahead. If the
lookahead use the same round robin strategy to distribute different
frames on the muti-threadpool as the frame encoder, is it better for the
muti-numa system? Thanks!

Post by Ximing Cheng
cores.
The x265 version is 1.7 release with command line
./x265 --input-res 1920x1080 --input input.yuv --bitrate 1200 --vbv-maxrate
1380 --fps 20 --early-skip --preset fast -o test1.hevc
but when ruuning on the server, CPU utilization ranges from 27% ~ 35% (<
40%) which means most of the CPU cores are not busy.
x265 [info]: HEVC encoder version 1.7x265 [info]: build info
--psnr used with AQ on: results will be invalid!x265 [warning]: --tune
psnr should be used if attempting to benchmark psnr!x265 [info]: Main
profile, Level-4 (Main tier)x265 [info]: Thread pool 0 using 36
threads on NUMA node 0x265 [info]: Thread pool 1 using 36 threads on
NUMA node 1x265 [info]: frame threads / pool features : 16 /
wpp(34 rows)+pmodex265 [warning]: VBV maxrate specified, but no
bufsize, ignoredx265 [info]: Coding QT: max CU size, min CU size : 32
/ 8x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intrax265 [info]: ME / range / subpel / merge : star / 57 / 1
/ 2x265 [info]: Keyframe min / max / scenecut : 20 / 250 /
40x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2x265
[info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1x265
[info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.3 / 32 / 1x265
[info]: Rate Control / qCompress : ABR-1200 kbps / 0.60x265
[info]: tools: rect amp rd=4 rdoq=2 early-skip signhide tmvp b-intra

--
Fun and success!
Mario *LigH* RohkrÃ€mer
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

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

Steve Borho

2015-08-03 15:53:24 UTC

Permalink

Post by Ximing Cheng
I found the lookahead JobProvider only process its tasks on the threadpool
zero (the first threadpool), this will destroy the load balance of the
muti-threadpool system as the frame encoders are distributed on
the muti-threadpool by round robin. The encoder could not fully use the CPU
resource as the HEVC algorithm's high correlation.
Some of the worker thread sometimes waiting for the Job to awaken them, but
lookahead could not awaken thread on the second threadpool. And the main
x265 encoder must wait for the output queue of the lookahead. If the
lookahead use the same round robin strategy to distribute different frames
on the muti-threadpool as the frame encoder, is it better for the muti-numa
system? Thanks!

Lookahead is generally not a bottleneck once it fills its output queue
and the frame encoders start working. I added timers within the frame
encoders which measure how much time the frame encoder sits idle,
waiting for a slice decision from the lookahead. You can see this with
--csv frames.csv --csv-log-level 1. After an encode, open frames.csv and
look at the DecideWait (ms) column.

You can verify this by encoding with --b-adapt 1, which vastly reduces
the amount of work performed by the lookahead. The DecideWait times
should reduce a bit, but I don't expect you'll see much improvement in
total utilization.

There are basically two reasons why HEVC has less parallelism than AVC
(leading to less utilization). First is the large CTU size (64x64 vs
16x16 macroblocks), reducing row granularity to one fourth. The second
is the new SAO loop filter, which adds an extra row of reference lag. On
the plus side we have WPP, which increases parallelism but often not
enough to make up for the CTU size and SAO.

Post by Ximing Cheng

Post by Ximing Cheng
The x265 version is 1.7 release with command line
./x265 --input-res 1920x1080 --input input.yuv --bitrate 1200 --vbv-maxrate
1380 --fps 20 --early-skip --preset fast -o test1.hevc
but when ruuning on the server, CPU utilization ranges from 27% ~ 35% (<
40%) which means most of the CPU cores are not busy.
x265 [info]: HEVC encoder version 1.7x265 [info]: build info
--psnr used with AQ on: results will be invalid!x265 [warning]: --tune
psnr should be used if attempting to benchmark psnr!x265 [info]: Main
profile, Level-4 (Main tier)x265 [info]: Thread pool 0 using 36
threads on NUMA node 0x265 [info]: Thread pool 1 using 36 threads on
NUMA node 1x265 [info]: frame threads / pool features : 16 /
wpp(34 rows)+pmodex265 [warning]: VBV maxrate specified, but no
bufsize, ignoredx265 [info]: Coding QT: max CU size, min CU size : 32
/ 8x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intrax265 [info]: ME / range / subpel / merge : star / 57 / 1
/ 2x265 [info]: Keyframe min / max / scenecut : 20 / 250 /
40x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2x265
[info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1x265
[info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.3 / 32 / 1x265
[info]: Rate Control / qCompress : ABR-1200 kbps / 0.60x265
[info]: tools: rect amp rd=4 rdoq=2 early-skip signhide tmvp b-intra

--
Steve Borho

Ximing Cheng

2015-08-07 03:43:50 UTC

Permalink

--csv-log-level 1 is broken in 1.7 release, x265.exe: unrecognized
option '--csv-log-level',
help!

Post by Ximing Cheng

Post by Ximing Cheng
I found the lookahead JobProvider only process its tasks on the

threadpool

Post by Ximing Cheng
zero (the first threadpool), this will destroy the load balance of the
muti-threadpool system as the frame encoders are distributed on
the muti-threadpool by round robin. The encoder could not fully use the

CPU

Post by Ximing Cheng
resource as the HEVC algorithm's high correlation.
Some of the worker thread sometimes waiting for the Job to awaken them,

but

Post by Ximing Cheng
lookahead could not awaken thread on the second threadpool. And the main
x265 encoder must wait for the output queue of the lookahead. If the
lookahead use the same round robin strategy to distribute different

frames

Post by Ximing Cheng
on the muti-threadpool as the frame encoder, is it better for the

muti-numa

Post by Ximing Cheng
system? Thanks!

Lookahead is generally not a bottleneck once it fills its output queue
and the frame encoders start working. I added timers within the frame
encoders which measure how much time the frame encoder sits idle,
waiting for a slice decision from the lookahead. You can see this with
--csv frames.csv --csv-log-level 1. After an encode, open frames.csv and
look at the DecideWait (ms) column.
You can verify this by encoding with --b-adapt 1, which vastly reduces
the amount of work performed by the lookahead. The DecideWait times
should reduce a bit, but I don't expect you'll see much improvement in
total utilization.
There are basically two reasons why HEVC has less parallelism than AVC
(leading to less utilization). First is the large CTU size (64x64 vs
16x16 macroblocks), reducing row granularity to one fourth. The second
is the new SAO loop filter, which adds an extra row of reference lag. On
the plus side we have WPP, which increases parallelism but often not
enough to make up for the CTU size and SAO.

Post by Ximing Cheng
On Tue, Jul 28, 2015 at 1:57 PM, Mario *LigH* Rohkr??mer <

Post by Mario *LigH* RohkrÃ¤mer
Hi Cheng.
This issue has been discussed before in the VideoHelp forum.
Parallelization is a bit more limited because dependencies between

tasks in

Post by Ximing Cheng

Post by Mario *LigH* RohkrÃ¤mer
HEVC algorithms are possibly more restrictive than in AVC algorithms

(many

Post by Ximing Cheng

Post by Mario *LigH* RohkrÃ¤mer
parts of the HEVC algorithm need to wait for others finishing

intermediate

Post by Ximing Cheng

Post by Mario *LigH* RohkrÃ¤mer
results, and splitting the video frame across too many slices would

hurt

Post by Ximing Cheng

Post by Mario *LigH* RohkrÃ¤mer
the encoding efficiency).
But it is easily possible to run several applications in parallel so

that

Post by Ximing Cheng

Post by Mario *LigH* RohkrÃ¤mer
they each get a share of available cores.
Am 28.07.2015, 03:58 Uhr, schrieb Ximing Cheng <
Hi, I am testing x265 with a two numa nodes server, each node has 36

cores.

Post by Ximing Cheng

Post by Mario *LigH* RohkrÃ¤mer

Post by Ximing Cheng

Post by Mario *LigH* RohkrÃ¤mer

Post by Ximing Cheng
40%) which means most of the CPU cores are not busy.
x265 [info]: HEVC encoder version 1.7x265 [info]: build info
--psnr used with AQ on: results will be invalid!x265 [warning]: --tune
psnr should be used if attempting to benchmark psnr!x265 [info]: Main
profile, Level-4 (Main tier)x265 [info]: Thread pool 0 using 36
threads on NUMA node 0x265 [info]: Thread pool 1 using 36 threads on
NUMA node 1x265 [info]: frame threads / pool features : 16 /
wpp(34 rows)+pmodex265 [warning]: VBV maxrate specified, but no
bufsize, ignoredx265 [info]: Coding QT: max CU size, min CU size : 32
/ 8x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2
intrax265 [info]: ME / range / subpel / merge : star / 57 / 1
/ 2x265 [info]: Keyframe min / max / scenecut : 20 / 250 /
40x265 [info]: Lookahead / bframes / badapt : 60 / 4 / 2x265
[info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 1x265
[info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.3 / 32 / 1x265
[info]: Rate Control / qCompress : ABR-1200 kbps / 0.60x265
[info]: tools: rect amp rd=4 rdoq=2 early-skip signhide tmvp b-intra

--
Steve Borho
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

Mario *LigH* Rohkrämer

2015-08-07 06:11:04 UTC

Permalink

--csv-log-level 1 is broken in 1.7 release,x265.exe: unrecognized option
'--csv-log-level',
help!

Which version exactly? I know there were some missing options before
v1.7+300, but with v1.7+392 the CSV log works well.

Will test later with v1.7+399 when it has been built...

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

Divya Manivannan

2015-08-07 06:38:58 UTC

Permalink

There is no --csv-log-level option in 1.7 release. To get the frame level
statistics in 1.7 release tip, you can use --log-level value greater than
or equal to frame along with --csv option.

--csv-log-level 1 is broken in 1.7 release,x265.exe: unrecognized option

Post by Ximing Cheng
'--csv-log-level',
help!

Which version exactly? I know there were some missing options before
v1.7+300, but with v1.7+392 the CSV log works well.
Will test later with v1.7+399 when it has been built...
--
Fun and success!
Mario *LigH* RohkrÃ€mer
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

Mario *LigH* Rohkrämer

2015-08-07 06:53:31 UTC

Permalink

Ah, so "v1.7 release" means "v1.7 without any later patches" ... well,
this one is pretty old now, considering the amount of development since.

Am 07.08.2015, 08:38 Uhr, schrieb Divya Manivannan

Post by Divya Manivannan
There is no --csv-log-level option in 1.7 release. To get the frame level
statistics in 1.7 release tip, you can use --log-level value greater than
or equal to frame along with --csv option.

Am 07.08.2015, 05:43 Uhr, schrieb Ximing Cheng
--csv-log-level 1 is broken in 1.7 release,x265.exe: unrecognized option

Post by Ximing Cheng
'--csv-log-level',
help!

Which version exactly? I know there were some missing options before
v1.7+300, but with v1.7+392 the CSV log works well.
Will test later with v1.7+399 when it has been built...
--
Fun and success!
Mario *LigH* Rohkrämer
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

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

Deepthi Nandakumar

2015-08-07 06:59:01 UTC

Permalink

Agreed - we're just waiting for some test failures to clear up before doing
this. I'm branching out for a 1.8 release but expect the bug fixes to take
a week or so.

Post by Mario *LigH* RohkrÃ¤mer
Ah, so "v1.7 release" means "v1.7 without any later patches" ... well,
this one is pretty old now, considering the amount of development since.
Am 07.08.2015, 08:38 Uhr, schrieb Divya Manivannan <
There is no --csv-log-level option in 1.7 release. To get the frame level

Post by Divya Manivannan
statistics in 1.7 release tip, you can use --log-level value greater than
or equal to frame along with --csv option.

--csv-log-level 1 is broken in 1.7 release,x265.exe: unrecognized option

Post by Ximing Cheng
'--csv-log-level',
help!

--
Fun and success!
Mario *LigH* RohkrÃ€mer
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

Ximing Cheng

2015-08-07 08:59:04 UTC

Permalink

Thanks!

On Fri, Aug 7, 2015 at 2:59 PM, Deepthi Nandakumar <

Post by Deepthi Nandakumar
Agreed - we're just waiting for some test failures to clear up before
doing this. I'm branching out for a 1.8 release but expect the bug fixes to
take a week or so.

Post by Divya Manivannan
statistics in 1.7 release tip, you can use --log-level value greater than
or equal to frame along with --csv option.
Am 07.08.2015, 05:43 Uhr, schrieb Ximing Cheng <

--csv-log-level 1 is broken in 1.7 release,x265.exe: unrecognized option

Post by Ximing Cheng
'--csv-log-level',
help!

--
Fun and success!
Mario *LigH* RohkrÃ€mer
_______________________________________________
x265-devel mailing list
https://mailman.videolan.org/listinfo/x265-devel

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