Re: [x265] Error x265 2.9+1: frame type not compatible with keyframe interval
Hi. Just a guess: Are you possibly reusing a 1st-pass statistics file from a different encode, or did you change parameters between 1st and 2nd pass which affect the GOP size limits or scene detection sensitivity? Just to exclude the most obvious first, before digging deeper if there was a known GOP type bug for this version specifically. Posting the whole command lines for both passes would certainly be helpful. Zero Un schrieb am 17.03.2019 um 13:17: Hello i have this mistake many times on a encode x265 [warning]: specified frame type (5) at 77330 is not compatible with keyframe interval x265 [error]: slice=I but 2pass stats say B ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel -- Fun and success! Mario *LigH* Rohkrämer maito:cont...@ligh.de ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
[x265] Error x265 2.9+1
Hello i have this mistake many times on a encode x265 [warning]: specified frame type (5) at 77330 is not compatible with keyframe interval x265 [error]: slice=I but 2pass stats say B ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
[x265] Issue #482: Leak Memory (multicoreware/x265)
New issue 482: Leak Memory https://bitbucket.org/multicoreware/x265/issues/482/leak-memory Hữu Quang Linh Lê: I found some input causing leak memory. This is crash information. ``` INFO: Seed: 3904123746 INFO: Loaded 1 modules (50397 inline 8-bit counters): 50397 [0x1267560, 0x1273a3d), INFO: Loaded 1 PC tables (50397 PCs): 50397 [0x1273a40,0x1338810), ./encoder-fuzzer: Running 1 inputs 1 time(s) each. Running: leak-034018c6753ae7d385399bf5c3071ba3863a95c8 = ==30238==ERROR: LeakSanitizer: detected memory leaks Direct leak of 984 byte(s) in 1 object(s) allocated from: #0 0x4b2f4e in posix_memalign /src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:218 #1 0xc2f80c in x265::x265_malloc(unsigned long) /src/x265/source/common/common.cpp:81:9 #2 0xc302d9 in x265_param_alloc /src/x265/source/common/param.cpp:95:25 #3 0x7f059d in x265_encoder_open_169 /src/x265/source/encoder/api.cpp:97:37 #4 0x6082d0 in x265_encode_image(void*, heif_image const*, heif_image_input_class) /src/libheif/libheif/heif_encoder_x265.cc:707:22 #5 0x5d52d4 in heif::HeifContext::Image::encode_image_as_hevc(std::__1::shared_ptr, heif_encoder*, heif_encoding_options const*, heif_image_input_class) /src/libheif/libheif/heif_context.cc:1700:27 #6 0x5d4791 in heif::HeifContext::encode_image(std::__1::shared_ptr, heif_encoder*, heif_encoding_options const*, heif_image_input_class, std::__1::shared_ptr&) /src/libheif/libheif/heif_context.cc:1608:28 #7 0x5b8f47 in heif_context_encode_image /src/libheif/libheif/heif.cc:1561:25 #8 0x60bfa8 in LLVMFuzzerTestOneInput /src/libheif/libheif/encoder_fuzzer.cc:161:9 #9 0x6465f5 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:529:15 #10 0x60e076 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:286:6 #11 0x619ba3 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9 #12 0x60d6ec in main /src/libfuzzer/FuzzerMain.cpp:19:10 #13 0x7f9cd365582f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) SUMMARY: AddressSanitizer: 984 byte(s) leaked in 1 allocation(s). ``` Do you think this is a bug? I want to report to you so that I can fix this soon. ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
[x265] Blocking on edges in most recent x265 commit
I just ran some short encodes with the most recent version of x265 from the mercurial repo and I'm seeing some odd blocking happening at hard edges with motion. I reverted to changeset: 12496:d97a256d46a7 (x86 primitive for ssim-rd) and the issue does not seem to be present in this version. I haven't had a chance to do a deep analysis of the video yet, but the blocks that are erroneous look large - probably an entire 64x64 CTU. -Blake ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
[x265] Issue #481: Bug reporting version 3.0 not selectable (multicoreware/x265)
New issue 481: Bug reporting version 3.0 not selectable https://bitbucket.org/multicoreware/x265/issues/481/bug-reporting-version-30-not-selectable flip -: When filing a bug report there is a dropdown box with some versions to select. This box only goes up to version 1.9 thus i can not select the latest 3.0 version ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
[x265] Issue #480: Compiler warnings on x265 3.0 (multicoreware/x265)
New issue 480: Compiler warnings on x265 3.0 https://bitbucket.org/multicoreware/x265/issues/480/compiler-warnings-on-x265-30 flip -: During compilation of handbrake, the following warnings/hints appear: ``` CC src/libbluray/bdnav/libbluray_la-uo_mask.lo /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/encoder/ratecontrol.cpp: In member function ‘int x265::RateControl::writeRateControlFrameStats(x265::Frame*, x265::RateControlEntry*)’: /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/encoder/ratecontrol.cpp:2864:21: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict] sprintf(deltaPOC, "%s%d~", deltaPOC, rpsWriter->deltaPOC[i]); ^~~~ /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/encoder/ratecontrol.cpp:2865:21: warning: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Wrestrict] sprintf(bUsed, "%s%d~", bUsed, rpsWriter->bUsed[i]); ^ ~ CC src/libbluray/decoders/libbluray_la-graphics_controller.lo CXX libAACdec/src/aacdec_hcr_bit.lo CXX libAACdec/src/aacdec_hcrs.lo /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/encoder/ratecontrol.cpp:2864:31: warning: ‘~’ directive writing 1 byte into a region of size between 0 and 127 [-Wformat-overflow=] sprintf(deltaPOC, "%s%d~", deltaPOC, rpsWriter->deltaPOC[i]); ^~~ In file included from /usr/include/stdio.h:873, from /usr/include/c++/8/cstdio:42, from /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/common/common.h:33, from /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/encoder/ratecontrol.cpp:30: /usr/include/x86_64-linux-gnu/bits/stdio2.h:36:34: note: ‘__builtin___sprintf_chk’ output between 3 and 140 bytes into a destination of size 128 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^~ __bos (__s), __fmt, __va_arg_pack ()); ~ /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/encoder/ratecontrol.cpp:2865:28: warning: ‘~’ directive writing 1 byte into a region of size between 0 and 39 [-Wformat-overflow=] sprintf(bUsed, "%s%d~", bUsed, rpsWriter->bUsed[i]); ^~~ In file included from /usr/include/stdio.h:873, from /usr/include/c++/8/cstdio:42, from /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/common/common.h:33, from /home/flip/programs/src/HandBrake/build/contrib/x265/x265_3.0/source/encoder/ratecontrol.cpp:30: /usr/include/x86_64-linux-gnu/bits/stdio2.h:36:34: note: ‘__builtin___sprintf_chk’ output between 3 and 42 bytes into a destination of size 40 return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^~ __bos (__s), __fmt, __va_arg_pack ()); ~ ``` Probably related to https://bitbucket.org/multicoreware/x265/issues/410/compiler-warnings https://bitbucket.org/multicoreware/x265/issues/423/linux-build-error But now it's half a year later so these are the "current" results. ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
[x265] Issue #479: x265 2.8: Build script x265_2.8\build\vc15-x86_64\multilib.bat doesn't work with Visual Studio Community 2017 (multicoreware/x265)
New issue 479: x265 2.8: Build script x265_2.8\build\vc15-x86_64\multilib.bat doesn't work with Visual Studio Community 2017 https://bitbucket.org/multicoreware/x265/issues/479/x265-28-build-script-x265_28-build-vc15 Former user: I have Visual Studio Community 2017 installed but failed to build x265 because VS2017 has changed the path of vcvarsall.bat and its default parameters. I have to make the following change to make x265_2.8\build\vc15-x86_64\multilib.bat to work with Visual Studio Community 2017: call "%VS150COMNTOOLS%\..\..\VC\Auxiliary\Build\vcvarsall.bat" x86_amd64 10.0.17763.0 Please update x265_2.8\build\vc15-x86_64\multilib.bat. Thanx! Jiong ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
