This value is not represented in the HEVC bitstream, which is why it
was not set previously. FFmpeg sets and needs it however, so make the
CLI set it as well to make sure we handle it correctly.
Depending on the distro, the pkg-config package name of crypto++ could
be either cryptopp or libcrypto++. This commit changes configure to
check for both instead of cryptopp only.
The rd-complexity of slow presets is better with a less agressive GOP.
Adding the GOP as part of the preset improved BDRate enough, that it
didn't make sense anymore to have a veryslow target the best BDRate.
Instead, push that responsibility to placebo by making it a little bit
faster.
Now that WPP is on by default, Valgrind is finding memory leaks on
these tests. It's not a priority so I'll just disable it for now.
==8120== Memcheck, a memory error detector
==8120== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8120== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8120== Command: /home/travis/build/Venti-/kvazaar/src/.libs/lt-kvazaar -i mandelbrot_264x130.yuv --input-res=264x130 -o test.265 -p4 -r2 --owf=1 --threads=2 --tiles-height-split=u2 --rd=0 --no-rdoq --no-deblock --no-sao --no-signhide --subme=0 --pu-depth-inter=1-3 --pu-depth-intra=2-3
==8120==
Disabling TMVP because tiles are used.
Compiled: INTEL, flags: MMX SSE SSE2
Detected: INTEL, flags: MMX SSE SSE2 SSE3 SSSE3 SSE41 SSE42
Available: sse2(2) sse41(1)
In use: sse2(1) sse41(1)
Input: mandelbrot_264x130.yuv, output: test.265
Video size: 264x136 (input=264x130)
==8120== Conditional jump or move depends on uninitialised value(s)
==8120== at 0x4E5FEE5: kvz_threadqueue_job_dep_add (threadqueue.c:616)
==8120== by 0x4E3DEAB: encoder_state_worker_encode_children (encoderstate.c:432)
==8120== by 0x4E3E219: encoder_state_encode (encoderstate.c:649)
==8120== by 0x4E3DE35: encoder_state_worker_encode_children (encoderstate.c:417)
==8120== by 0x4E3E219: encoder_state_encode (encoderstate.c:649)
==8120== by 0x4E3DE35: encoder_state_worker_encode_children (encoderstate.c:417)
==8120== by 0x4E3E219: encoder_state_encode (encoderstate.c:649)
==8120== by 0x4E3ECBD: kvz_encode_one_frame (encoderstate.c:941)
==8120== by 0x4E4DA22: kvazaar_encode (kvazaar.c:229)
==8120== by 0x4E4E228: kvazaar_field_encoding_adapter (kvazaar.c:280)
==8120== by 0x40137F: main (encmain.c:436)
==8120==
lt-kvazaar: threadqueue.c:618: kvz_threadqueue_job_dep_add: Assertion `job && depends_on' failed.
==8120==
==8120== HEAP SUMMARY:
==8120== in use at exit: 1,320,764 bytes in 568 blocks
==8120== total heap usage: 584 allocs, 16 frees, 1,330,691 bytes allocated
==8120==
==8120== 112 bytes in 1 blocks are definitely lost in loss record 27 of 88
==8120== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8120== by 0x4E46BA5: kvz_image_alloc (image.c:49)
==8120== by 0x401E12: input_read_thread (encmain.c:183)
==8120== by 0x55EDE99: start_thread (pthread_create.c:308)
==8120==
==8120== 272 bytes in 1 blocks are possibly lost in loss record 41 of 88
==8120== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8120== by 0x4012034: _dl_allocate_tls (dl-tls.c:297)
==8120== by 0x55EEABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8120== by 0x4012B9: main (encmain.c:404)
==8120==
==8120== 544 bytes in 2 blocks are possibly lost in loss record 45 of 88
==8120== at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8120== by 0x4012034: _dl_allocate_tls (dl-tls.c:297)
==8120== by 0x55EEABC: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==8120== by 0x4E5EF65: kvz_threadqueue_init (threadqueue.c:308)
==8120== by 0x4E3BD2F: kvz_encoder_control_init (encoder.c:173)
==8120== by 0x4E4DD7E: kvazaar_open (kvazaar.c:80)
==8120== by 0x401112: main (encmain.c:346)
==8120==
==8120== 53,856 bytes in 1 blocks are possibly lost in loss record 81 of 88
==8120== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8120== by 0x4E46BEC: kvz_image_alloc (image.c:59)
==8120== by 0x401E12: input_read_thread (encmain.c:183)
==8120== by 0x55EDE99: start_thread (pthread_create.c:308)
==8120==
==8120== LEAK SUMMARY:
==8120== definitely lost: 112 bytes in 1 blocks
==8120== indirectly lost: 0 bytes in 0 blocks
==8120== possibly lost: 54,672 bytes in 4 blocks
==8120== still reachable: 1,265,980 bytes in 563 blocks
==8120== suppressed: 0 bytes in 0 blocks
==8120== Reachable blocks (those to which a pointer was found) are not shown.
==8120== To see them, rerun with: --leak-check=full --show-reachable=yes
==8120==
==8120== For counts of detected and suppressed errors, rerun with: -v
==8120== Use --track-origins=yes to see where uninitialised values come from
==8120== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 2 from 2)
GOPs with depth 1 had the same structure as those with depth 2:
g4d3t1 = 3 2 3 1
g4d2t1 = 2 2 2 1
g4d1t1 = 2 2 2 1
It now results in the correct:
g4d1t1 = 1 1 1 1
Coding inter without GOP of any kind really isn't a very sensible
default. Defaulting to B-GOP of some kind would be more better,
but lp-gop is more robust for now.
Use the vectorized general SSE41 inter SAD in AVX reg_sad for shapes
for which we don't have AVX versions yet.
Also improves speed of --smp and --amp a lot. Got a 1.25x speedup for:
--preset=ultrafast -q 27 --gop=lp-g4d3r3t1 --me-early-termination=on --rd=1 --pu-depth-inter=1-3 --smp --amp
* Suite speed_tests:
-PASS inter_sad: 0.898M x reg_sad(64x63):x86_asm_avx (1000 ticks, 1.000 sec)
+PASS inter_sad: 2.503M x reg_sad(64x63):x86_asm_avx (1000 ticks, 1.000 sec)
-PASS inter_sad: 115.054M x reg_sad(1x1):x86_asm_avx (1000 ticks, 1.000 sec)
+PASS inter_sad: 133.577M x reg_sad(1x1):x86_asm_avx (1000 ticks, 1.000 sec)
Add tests for the extreme shapes that can happen when a motion vector
points outside the frame. A single pixel case where it probably doesn't
make sense to call a vectorized function, and the maximum size where it
definitely does make sense to call a vectorized function.
Add implementations for these functions that process the image line by
line instead of using the 16x16 function to process block by block.
The 32x32 is around 30% faster, and 64x64 is around 15% faster,
on Haswell.
PASS inter_sad: 28.744M x reg_sad(32x32):x86_asm_avx (1014 ticks, 1.014 sec)
PASS inter_sad: 7.882M x reg_sad(64x64):x86_asm_avx (1014 ticks, 1.014 sec)
to
PASS inter_sad: 37.828M x reg_sad(32x32):x86_asm_avx (1014 ticks, 1.014 sec)
PASS inter_sad: 9.081M x reg_sad(64x64):x86_asm_avx (1014 ticks, 1.014 sec)
Inter SAD accesses pixels directly from the frame buffers, so give it
a 4k frame to work in for more realistic results. The old test used
intra test data, which consist of tiny buffers.
Measured a cumulative effect of 1.04x speedup, when inter search is
used a lot. Not a huge difference.
--preset=ultrafast --me=tz --gop=lp-g4d3r2t2 --wpp --owf=4 --threads=14
Sometimes the tests overrun their time limit by varying amounts.
Return calls per second based on the amount of time actually spent in
the loop instead of how much time we tried to spend in the loop.
