Quote:
Originally Posted by MoSal
Is the first L in LGPL intentional?
|
Yes.
Quote:
Originally Posted by LigH
No clue why mine is slower. Plain GCC 7.3.0 build. What's different in jonatans', new dev revision or higher CPU optimization while compiling C sources?
|
I don't know really. Mine is built from xvc version 2, master branch, commit 283009f using the Visual Studio compiler.
I also get much slower encoding times with your build. Will try to look further into what causes the difference.
Quote:
Originally Posted by colinhunt
xvcenc.exe -input-file moto.yuv -input-width 1920 -input-height 1080 -input-bitdepth 8 -framerate 24 -verbose 1 -threads 20 -speed-mode 2 -qp 30 -explicit-encoder-settings "aqp_strength 16" -output-file output.xvc
v1 binary: 183 minutes, no multi-threading.
v2 binary (LigH's): 94 minutes. 20 threads, CPU usage peaked at 47%.
v2 binary (Jonatan's): 51,3 minutes. 20 threads, RAM usage 5.9GB, CPU usage peaked at 56%.
v2 binary (Jonatan's): 51 minutes. 10 threads, CPU usage peaked at 55%.
v2 binary (Jonatan's): 51 minutes. 40 threads, RAM usage 8.5GB, CPU usage peaked at 59%.
v2 binary (Jonatan's): 51 minutes. 8 threads, RAM usage 2.1GB.
|
Thanks for the extensive testing colinhunt. The reason why you do not see higher speed-up might be related to that the sequence you are encoding is roughly equally long as the segment length you are using. If you would be using a sequence that was 4 times as long or if you would set -max-keypic-distance to something like 160 you might get a higher speed-up factor (but that would of course also affect the compressed result).