Open h.265 video codec implementation.

libde265 - open h.265 codec implementation

libde265

libde265 is an open source implementation of the h.265 video codec. It is written from scratch and has a plain C API to enable a simple integration into other software.

libde265 supports WPP and tile-based multithreading and includes SSE optimizations. The decoder includes all features of the Main profile and correctly decodes almost all conformance streams (see [wiki page]).

A list of supported features are available in the wiki.

For latest news check our website at http://www.libde265.org

The library comes with two example programs:

  • dec265, a simple player for raw h.265 bitstreams. It serves nicely as an example program how to use libde265.

  • sherlock265, a Qt-based video player with the additional capability to overlay some graphical representations of the h.265 bitstream (like CU-trees, intra-prediction modes).

Example bitstreams can be found, e.g., at this site: ftp://ftp.kw.bbc.co.uk/hevc/hm-10.1-anchors/bitstreams/ra_main/

Approximate performance for WPP, non-tiles streams (measured using the timehevc tool from the GStreamer plugin). The tool plays a Matroska movie to the GStreamer fakesink and measures the average framerate.

Resolution avg. fps CPU usage
720p 284 fps 39 %
1080p 150 fps 45 %
4K 36 fps 56 %

Environment:

  • Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (4 physical CPU cores)
  • Ubuntu 12.04, 64bit
  • GStreamer 0.10.36

Building

Build Status Build Status

If you got libde265 from the git repository, you will first need to run the included autogen.sh script to generate the configure script.

libde265 has no dependencies on other libraries, but both optional example programs have dependencies on:

  • SDL (optional for dec265's YUV overlay output),

  • Qt (required for sherlock265),

  • libswscale (required for sherlock265 if libvideogfx is not available).

  • libvideogfx (required for sherlock265 if libswscale is not available, optional for dec265).

Libvideogfx can be obtained from http://www.dirk-farin.net/software/libvideogfx/index.html or http://github.com/farindk/libvideogfx

You can disable building of the example programs by running ./configure with

  --disable-dec265        Do not build the dec265 decoder program.
  --disable-sherlock265   Do not build the sherlock265 visual inspection program.

Additional logging information can be turned on and off using these ./configure flags:

  --enable-log-error      turn on logging at error level (default=yes)
  --enable-log-info       turn on logging at info level (default=no)
  --enable-log-trace      turn on logging at trace level (default=no)

Build using cmake

cmake scripts to build libde265 and the sample scripts dec265 and enc265 are included and can be compiled using these commands:

mkdir build
cd build
cmake ..
make

See the cmake documentation for further information on using cmake on other platforms.

Prebuilt binaries

Binary packages can be obtained from this launchpad site.

Software using libde265

Libde265 has been integrated into these applications:

License

The library libde265 is distributed under the terms of the GNU Lesser General Public License. The sample applications are distributed under the terms of the MIT license.

See COPYING for more details.

Copyright (c) 2013-2014 Struktur AG Contact: Dirk Farin [email protected]

Comments
  • dump header info

    dump header info

    hi,

    i use -d option to dump headers while decoding a stream with multiple tiles and one slice per frame...but when i see the info, i see multiple slices, even if i decode one frame (using option -f 1) ....for example i decode one frame with one slice and 4 tiles....shouldn't i see 1 slice and 3 entry points? Instead there seem to be 4 slices info with respective entry points

  • Extracting DCT coefficients for every frame in an encoded video.

    Extracting DCT coefficients for every frame in an encoded video.

    I've been using the prebuild dec265 for decoding encoded binaries (.bin) videos. I saw that the acceleration-speed folder has methods for computing the DCT coefficients, however the make fails for acceleration-speed for me. Is there any way I can perhaps call a function via dec265 itself, so it writes all the DCT coefficients in a file as it runs the video?

  • Travis no longer green on master

    Travis no longer green on master

    Travis is no longer green on master after commit 0338ac5: https://travis-ci.org/strukturag/libde265/builds/85284996

    Also the fuzzing streams are failing after commit 8ec4e93: https://travis-ci.org/strukturag/libde265/builds/85519474

    Please check and make sure to keep Travis green/stable at least on the master branch in the future.

  • Video cannot be decoded

    Video cannot be decoded

    Hi All,

    I try to use libde265 decoder our company compressed video, which can be downloaded here (https://github.com/qyljcy/libde265/blob/master/testvideo/GangnamStyle-480p.mp4). It compressed by X265

    But no video output. The video can display well in ffmpeg or OpenHEVC, why not de265?

    I try to use modified ffmpeg(https://github.com/farindk/ffmpeg), but this ffmpeg version is too low.

    Hope some expert can help me to check it.

    Best regards, Jesse

  • Added parentheses.

    Added parentheses.

    This PR adds parentheses to prevent the use of the max define. We use this library inside the @ImageMagick project and our build fails without these changes.

  • Completion of error handling

    Completion of error handling

    I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

    Would you like to add more error handling for return values from functions like the following?

  • warning: converting to non-pointer type 'DWORD'

    warning: converting to non-pointer type 'DWORD'

    threads.cc:213:14: warning: converting to non-pointer type 'DWORD' {aka 'long unsigned int'} from NULL [-Wconversion-null] 213 | return NULL; | ^~~~ threads.cc:241:10: warning: converting to non-pointer type 'DWORD' {aka 'long unsigned int'} from NULL [-Wconversion-null] 241 | return NULL; | ^~~~

  • Use libde265_min and libde265_max

    Use libde265_min and libde265_max

    This PR changes std::min to libde265_min and std::max to libde265_max. We use this library inside the @ImageMagick project and our build fails without these changes.

  • Heap-buffer-overflow WRITE 4 (7706)

    Heap-buffer-overflow WRITE 4 (7706)

    The @ImageMagick project is using https://github.com/google/oss-fuzz to find bugs in our own library and in libraries that we use. The fuzzer found an issue and we think this is an issue that should be resolved in the library that we use. This issue is posted under the url https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7706 that is not publicly visible yet but added as a link for future reference. Below are the details of the issue that can be reproduced using the following technique: https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md

    Stacktrace:

    ==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62100003bf38 at pc 0x000000c3b3bd bp 0x7fff79e998d0 sp 0x7fff79e998c8
    --
      | WRITE of size 4 at 0x62100003bf38 thread T0
      | SCARINESS: 36 (4-byte-write-heap-buffer-overflow)
      | #0 0xc3b3bc in decoder_context::process_reference_picture_set(slice_segment_header*) libde265/libde265/decctx.cc:1688:24
      | #1 0xc336f1 in decoder_context::process_slice_segment_header(slice_segment_header*, de265_error*, long, nal_header*, void*) libde265/libde265/decctx.cc:2064:7
      | #2 0xc31f47 in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) libde265/libde265/decctx.cc:639:7
      | #3 0xc3716c in decoder_context::decode_NAL(NAL_unit*) libde265/libde265/decctx.cc:1230:11
      | #4 0xc376a7 in decoder_context::decode(int*) libde265/libde265/decctx.cc:1318:16
      | #5 0xad3b06 in decodeH265Image imagemagick/coders/heic.c:933:11
      | #6 0xad1b2e in ReadHEICImage imagemagick/coders/heic.c:1176:9
      | #7 0x6ced88 in ReadImage imagemagick/MagickCore/constitute.c:500:13
      | #8 0x669ba5 in BlobToImage imagemagick/MagickCore/blob.c:469:13
      | #9 0x5b58f2 in Magick::Image::read(Magick::Blob const&) imagemagick/Magick++/lib/Image.cpp:4015:12
      | #10 0x52984e in LLVMFuzzerTestOneInput imagemagick/Magick++/fuzz/encoder_fuzzer.cc:46:11
      | #11 0x553561 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:517:13
      | #12 0x52a60a in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
      | #13 0x535fbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:703:9
      | #14 0x529cac in main /src/libfuzzer/FuzzerMain.cpp:20:10
      | #15 0x7ff2a6e3a82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
      | #16 0x41e868 in _start
      |  
      | 0x62100003bf38 is located 0 bytes to the right of 4664-byte region [0x62100003ad00,0x62100003bf38)
      | allocated by thread T0 here:
      | #0 0x525288 in operator new(unsigned long) _asan_rtl_
      | #1 0xc2c4f7 in de265_new_decoder libde265/libde265/de265.cc:218:26
      | #2 0xad1336 in ReadHEICImage imagemagick/coders/heic.c:1145:17
      | #3 0x6ced88 in ReadImage imagemagick/MagickCore/constitute.c:500:13
      | #4 0x669ba5 in BlobToImage imagemagick/MagickCore/blob.c:469:13
      | #5 0x5b58f2 in Magick::Image::read(Magick::Blob const&) imagemagick/Magick++/lib/Image.cpp:4015:12
      | #6 0x52984e in LLVMFuzzerTestOneInput imagemagick/Magick++/fuzz/encoder_fuzzer.cc:46:11
      | #7 0x553561 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:517:13
      | #8 0x52a60a in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
      | #9 0x535fbb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:703:9
      | #10 0x529cac in main /src/libfuzzer/FuzzerMain.cpp:20:10
      | #11 0x7ff2a6e3a82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
      |  
      | SUMMARY: AddressSanitizer: heap-buffer-overflow (/mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds_imagemagick_6c758f2561112e17568a05126726c2ca513bfabc/revisions/encoder_heic_fuzzer+0xc3b3bc)
      | Shadow bytes around the buggy address:
      | 0x0c427ffff790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      | 0x0c427ffff7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      | 0x0c427ffff7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      | 0x0c427ffff7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      | 0x0c427ffff7d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      | =>0x0c427ffff7e0: 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa fa
      | 0x0c427ffff7f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      | 0x0c427ffff800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      | 0x0c427ffff810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      | 0x0c427ffff820: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      | 0x0c427ffff830: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      | Shadow byte legend (one shadow byte represents 8 application bytes):
      | Addressable:           00
      | Partially addressable: 01 02 03 04 05 06 07
      | Heap left redzone:       fa
      | Freed heap region:       fd
      | Stack left redzone:      f1
      | Stack mid redzone:       f2
      | Stack right redzone:     f3
      | Stack after return:      f5
      | Stack use after scope:   f8
      | Global redzone:          f9
      | Global init order:       f6
      | Poisoned by user:        f7
      | Container overflow:      fc
      | Array cookie:            ac
      | Intra object redzone:    bb
      | ASan internal:           fe
      | Left alloca redzone:     ca
      | Right alloca redzone:    cb
      | ==1==ABORTING
    

    Links: https://github.com/strukturag/libde265/blob/5c0a672f20d944b3a16aabdb373f0c0736aab3bb/libde265/decctx.cc#L1688 https://github.com/strukturag/libde265/blob/5c0a672f20d944b3a16aabdb373f0c0736aab3bb/libde265/de265.cc#L218

    Commit: 5c0a672f20d944b3a16aabdb373f0c0736aab3bb Testcase file: clusterfuzz-testcase-minimized-encoder_heic_fuzzer-5918050164408320.zip

  • How To Compile?

    How To Compile?

    I'm on Windows, and I have CMAKE, MAKE, arm-none-eabi, and a GCC compiler installed, and I'm trying to compile for an ARM11 device. (No, I can't compile on the device, it's not running Linux.)

    I need to decode H.265 video streaming over the local network on the device, and it doesn't have hardware h264 or h265 support. (It does however have hardware YUV <-> RGB, which is useful.)

    The video is being muxed and demuxed in a custom audio/video format I wrote (I'll put it on GitHub when it's finished), because I got fed up with MP4 and MOV refusing to stream properly.

    I tried just adding the 'libde265' folder to my project and compiling, but that didn't work.

    First problem, my compiler isn't configured to recognize '.cc' extension, so I wrote a script to rename '.cc' to '.cpp' ('cause I like writing scripts.) The includes were written like #include <libde265/whatever.h>, so the compiler couldn't find the files. I wrote a script to fix that as well, which seemed to work. de265-version.h is missing, so I renamed de265-version.h.in to de265-version.h and manually put the version where it clearly goes. But even after all that, the compilation errors just kept piling up, so eventually I just gave up trying to solve them. Obviously, the library isn't meant to be compiled this way.

    So then, how is it supposed to be compiled? I tried the instructions in the Build section of the README, but cmake just generates a bunch of useless garbage in the build folder, and make says it couldn't find a Makefile.

  • undeclared identifier NULL on FreeBSD

    undeclared identifier NULL on FreeBSD

    The following error happens when trying to build libde265 1.0.2 on FreeBSD.

    The newer FreeBSD releases use Clang as the default compiler, which give the error below. I have tested a old FreeBSD that still has GCC as default compiler build this code fine without any changes.

    Disabling the #define in libde265/util.h fixes the build but I'm not sure that it is the right thing to do.

    /bin/sh ../../../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I../../.. -I../.. -pipe -g -fstack-protector -fno-strict-aliasing -Werror=return-type -Werror=unused-result -Werror=reorder -std=gnu++11 -DDE265_LOG_ERROR -MT libde265_encoder_algo_la-algo.lo -MD -MP -MF .deps/libde265_encoder_algo_la-algo.Tpo -c -o libde265_encoder_algo_la-algo.lo test -f 'algo.cc' || echo './'algo.cc libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../../.. -I../.. -pipe -g -fstack-protector -fno-strict-aliasing -Werror=return-type -Werror=unused-result -Werror=reorder -std=gnu++11 -DDE265_LOG_ERROR -MT libde265_encoder_algo_la-algo.lo -MD -MP -MF .deps/libde265_encoder_algo_la-algo.Tpo -c algo.cc -fPIC -DPIC -o .libs/libde265_encoder_algo_la-algo.o In file included from algo.cc:23: In file included from ../../../libde265/encoder/algo/algo.h:26: In file included from ../../../libde265/encoder/encode.h:26: ../../../libde265/image.h:86:26: error: use of undeclared identifier 'NULL' MetaDataArray() { data=NULL; data_size=0; log2unitSize=0; width_in_uni... ^ /usr/include/sys/_null.h:35:14: note: expanded from macro 'NULL'

    define NULL nullptr

                ^
    

    ../../../libde265/util.h:75:17: note: expanded from macro 'nullptr'

    define nullptr NULL

                ^
    
  • Segmentation fault in apply_sao_internal<unsigned short> when decoding image multiple times

    Segmentation fault in apply_sao_internal when decoding image multiple times

    Hello,

    I have a weird case.

    This file do not crash heif-convert and it also don't crash my code when I attempt to decode it only once: Segmentation_fault_apply_sao_internal.zip

    However when I try to run my code in a loop (decoding the same input again and again), I get a crash sooner or later. When I run my program natively, it crashes in during the 2nd iteration. When I run the same binary with valgrind, only 17th iteration crashed.

    #0  0x00007ffff635b07d in apply_sao_internal<unsigned short> (img=<optimized out>, xCtb=<optimized out>, yCtb=<optimized out>, shdr=<optimized out>, cIdx=2, nSW=<optimized out>, nSH=<optimized out>, in_img=0x5555555bdf00, in_stride=144, 
        out_img=0x5555555e5d20, out_stride=144) at sao.cc:252
    #1  0x00007ffff635bdfb in apply_sao<unsigned char> (img=<optimized out>, [email protected]=4, yCtb=<optimized out>, [email protected]=0x5555555f8280, [email protected]=2, [email protected]=32, nSH=32, 
        in_img=0x5555555bdf00 "\213\003\260\003\352\003\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\006\004\377\003\366\003\366\003\366\003\366\003\366\003\366\003\355\003\346\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003a\003a\003a\003W\003O\003C\003A\003=\003\070\003\062\003+\003$\003\035\003\026\003\017\003\t\003\004\003", in_stride=144, 
        out_img=0x5555555e5d20 "\213\003\260\003\352\003\v\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\017\004\v\004\006\004\377\003\367\003\366\003\366\003\366\003\366\003\366\003\355\003\346\003\336\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003\335\003b\003a\003a\003W\003O\003C\003A\003=\003\070\003\062\003+\003$\003\035\003\026\003\017\003\t\003\004\003", out_stride=144) at sao.cc:270
    #2  0x00007ffff635a057 in thread_task_sao::work (this=0x555555599230) at sao.cc:457
    #3  0x00007ffff6369255 in worker_thread (pool_ptr=0x555555595bf8) at threads.cc:233
    #4  0x00007ffff6eaf37a in start_thread () from /lib64/libc.so.6
    #5  0x00007ffff6f3022c in clone3 () from /lib64/libc.so.6
    
    ==12569== Conditional jump or move depends on uninitialised value(s)
    ==12569==    at 0x904304D: void edge_filtering_luma_internal<unsigned char>(de265_image*, bool, int, int, int, int) (deblock.cc:622)
    ==12569==    by 0x9040E63: edge_filtering_luma(de265_image*, bool, int, int, int, int) (deblock.cc:714)
    ==12569==    by 0x90410FD: thread_task_deblock_CTBRow::work() (deblock.cc:980)
    ==12569==    by 0x9070254: worker_thread(void*) (threads.cc:233)
    ==12569==    by 0x5788379: start_thread (in /lib64/libc.so.6)
    ==12569==    by 0x580833F: clone (in /lib64/libc.so.6)
    ==12569== 
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 1
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 2
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 3
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 4
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 5
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 6
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 7
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 8
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 9
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 10
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 11
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 12
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 13
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 14
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 15
    libheif error: Decoder plugin generated an error: Unspecified
    Failed to read image!
    Iteration 16
    ==12569== Conditional jump or move depends on uninitialised value(s)
    ==12569==    at 0x906206E: void apply_sao_internal<unsigned short>(de265_image*, int, int, slice_segment_header const*, int, int, int, unsigned short const*, int, unsigned short*, int) (sao.cc:251)
    ==12569==    by 0x9062DFA: void apply_sao<unsigned char>(de265_image*, int, int, slice_segment_header const*, int, int, int, unsigned char const*, int, unsigned char*, int) (sao.cc:270)
    ==12569==    by 0x9061015: thread_task_sao::work() (sao.cc:453)
    ==12569==    by 0x9070254: worker_thread(void*) (threads.cc:233)
    ==12569==    by 0x5788379: start_thread (in /lib64/libc.so.6)
    ==12569==    by 0x580833F: clone (in /lib64/libc.so.6)
    ==12569== 
    ==12569== Invalid read of size 1
    ==12569==    at 0x906207D: void apply_sao_internal<unsigned short>(de265_image*, int, int, slice_segment_header const*, int, int, int, unsigned short const*, int, unsigned short*, int) (sao.cc:252)
    ==12569==    by 0x9062DFA: void apply_sao<unsigned char>(de265_image*, int, int, slice_segment_header const*, int, int, int, unsigned char const*, int, unsigned char*, int) (sao.cc:270)
    ==12569==    by 0x9061015: thread_task_sao::work() (sao.cc:453)
    ==12569==    by 0x9070254: worker_thread(void*) (threads.cc:233)
    ==12569==    by 0x5788379: start_thread (in /lib64/libc.so.6)
    ==12569==    by 0x580833F: clone (in /lib64/libc.so.6)
    ==12569==  Address 0x124d30cc is not stack'd, malloc'd or (recently) free'd
    
  • Segmentation fault in derive_spatial_luma_vector_prediction

    Segmentation fault in derive_spatial_luma_vector_prediction

    Hello,

    I am able to reproduce crash with: Segmentation_fault.zip

    running heif-convert clusterfuzz-testcase-minimized-kimgio_heif_fuzzer-4987055163179008.heic output3.png

    #0  0x00007ffff73ba579 in derive_spatial_luma_vector_prediction ([email protected]=0x55555557ce10, [email protected]=0x5555555865b0, [email protected]=0x555555586020, [email protected]=72, [email protected]=120, [email protected]=8,
        xP=72, yP=120, nPbW=4, nPbH=8, X=0, refIdxLX=0, partIdx=0, out_availableFlagLXN=0x7fffffff8286 "\001", out_mvLXN=0x7fffffff827e) at motion.cc:1739
    #1  0x00007ffff73babfa in fill_luma_motion_vector_predictors ([email protected]=0x55555557ce10, [email protected]=0x555555586020, [email protected]=0x5555555865b0, [email protected]=72, [email protected]=120, [email protected]=8, xP=72,
        yP=120, nPbW=4, nPbH=8, l=0, refIdx=0, partIdx=0, out_mvpList=0x7fffffff8310) at motion.cc:1905
    #2  0x00007ffff73bad85 in luma_motion_vector_prediction ([email protected]=0x55555557ce10, [email protected]=0x555555586020, [email protected]=0x5555555865b0, motion=..., [email protected]=72, [email protected]=120, nCS=8, xP=72,
        yP=120, nPbW=4, nPbH=8, l=0, refIdx=0, partIdx=0) at motion.cc:1978
    #3  0x00007ffff73bb011 in motion_vectors_and_ref_indices ([email protected]=0x55555557ce10, [email protected]=0x555555586020, [email protected]=0x5555555865b0, motion=..., [email protected]=72, [email protected]=120, xB=0, yB=0,
        nCS=8, nPbW=4, nPbH=8, partIdx=0, out_vi=0x7fffffff847c) at motion.cc:2062
    #4  0x00007ffff73bc23d in decode_prediction_unit (ctx=0x55555557ce10, shdr=0x555555586020, img=0x5555555865b0, motion=..., [email protected]=72, [email protected]=120, xB=0, yB=0, nCS=8, nPbW=4, nPbH=8, partIdx=0)
        at motion.cc:2102
    #5  0x00007ffff73ca435 in read_prediction_unit ([email protected]=0x7fffffff8840, [email protected]=72, [email protected]=120, [email protected]=0, [email protected]=0, [email protected]=4, nPbH=8, ctDepth=3, nCS=8, partIdx=0)
        at slice.cc:4136
    #6  0x00007ffff73cb74b in read_coding_unit ([email protected]=0x7fffffff8840, [email protected]=72, [email protected]=120, [email protected]=3, [email protected]=3) at slice.cc:4504
    #7  0x00007ffff73cbc79 in read_coding_quadtree (tctx=0x7fffffff8840, x0=72, y0=120, log2CbSize=3, ctDepth=3) at slice.cc:4652
    #8  0x00007ffff73cbbaa in read_coding_quadtree (tctx=0x7fffffff8840, x0=64, y0=112, log2CbSize=4, ctDepth=2) at slice.cc:4645
    #9  0x00007ffff73cbbf6 in read_coding_quadtree (tctx=0x7fffffff8840, x0=64, y0=96, log2CbSize=5, ctDepth=1) at slice.cc:4641
    #10 0x00007ffff73cbbf6 in read_coding_quadtree ([email protected]=0x7fffffff8840, [email protected]=64, [email protected]=64, log2CbSize=6, [email protected]=0) at slice.cc:4641
    #11 0x00007ffff73cbd6a in read_coding_tree_unit ([email protected]=0x7fffffff8840) at slice.cc:2861
    #12 0x00007ffff73cc073 in decode_substream ([email protected]=0x7fffffff8840, [email protected]=false, [email protected]=true) at slice.cc:4741
    #13 0x00007ffff73cc460 in read_slice_segment_data ([email protected]=0x7fffffff8840) at slice.cc:5054
    #14 0x00007ffff73a78d8 in decoder_context::decode_slice_unit_sequential ([email protected]=0x55555557ce10, [email protected]=0x5555555a6f80, [email protected]=0x5555555a7230) at decctx.cc:852
    #15 0x00007ffff73a8a73 in decoder_context::decode_slice_unit_parallel ([email protected]=0x55555557ce10, [email protected]=0x5555555a6f80, [email protected]=0x5555555a7230) at decctx.cc:954
    #16 0x00007ffff73a8b8c in decoder_context::decode_some ([email protected]=0x55555557ce10, [email protected]=0x7fffffffd210) at decctx.cc:739
    #17 0x00007ffff73ab1a1 in decoder_context::read_slice_NAL ([email protected]=0x55555557ce10, reader=..., [email protected]=0x55555557ea60, nal_hdr=...) at decctx.cc:697
    #18 0x00007ffff73ab2cd in decoder_context::decode_NAL ([email protected]=0x55555557ce10, nal=0x55555557ea60) at decctx.cc:1239
    #19 0x00007ffff73ab5fe in decoder_context::decode (this=0x55555557ce10, more=0x7fffffffd334) at decctx.cc:1327
    #20 0x00007ffff739ff44 in de265_decode (de265ctx=<optimized out>, more=<optimized out>) at de265.cc:352
    #21 0x00007ffff7f760b3 in libde265_v1_decode_image (decoder_raw=0x55555557bd60, out_img=0x7fffffffd3f0) at plugins/heif_decoder_libde265.cc:324
    #22 0x00007ffff7f53e27 in heif::HeifContext::decode_image_planar (this=0x5555555780f0, ID=<optimized out>, img=std::shared_ptr<heif::HeifPixelImage> (empty) = {...},
        [email protected]=heif_colorspace_RGB, [email protected]=0x55555557bea0, alphaImage=false) at heif_context.cc:1181
    #23 0x00007ffff7f550b3 in heif::HeifContext::decode_image_user (this=<optimized out>, ID=<optimized out>, img=std::shared_ptr<heif::HeifPixelImage> (empty) = {...}, out_colorspace=heif_colorspace_RGB,
        out_chroma=heif_chroma_interleaved_RRGGBB_BE, options=0x55555557bea0) at heif_context.cc:1088
    #24 0x00007ffff7f42d8e in heif_decode_image (in_handle=0x55555557bf40, out_img=0x7fffffffd868, colorspace=<optimized out>, chroma=<optimized out>, options=<optimized out>) at heif.cc:946
    #25 0x0000555555559644 in main (argc=<optimized out>, argv=<optimized out>) at heif_convert.cc:329
    
  • Assertion `scaling_list_pred_matrix_id_delta==3' failed.

    Assertion `scaling_list_pred_matrix_id_delta==3' failed.

    Hello, I built libde265 and libheif from git and I am able to trigger following assert with scaling_list_pred_matrix_id_delta.zip

    heif-convert clusterfuzz-testcase-minimized-kimgio_heif_fuzzer-6222100054016000.fuzz output.png
    File contains 1 image
    heif-convert: sps.cc:931: de265_error read_scaling_list(bitreader*, const seq_parameter_set*, scaling_list_data*, bool): Assertion `scaling_list_pred_matrix_id_delta==3' failed.
    

    Same file in GIMP 2.99.14 for Windows create following message: Assertion failed: scaling_list_pred_matrix_id_delta==3, file ../../libde265-1.0.9/libde265/sps.cc, line 931

    There is another case https://github.com/strukturag/libde265/issues/313 which looks similar.

    #0  0x00007ffff7ab0fac in __pthread_kill_implementation () from /lib64/libc.so.6
    #1  0x00007ffff7a63b62 in raise () from /lib64/libc.so.6
    #2  0x00007ffff7a4e471 in abort () from /lib64/libc.so.6
    #3  0x00007ffff7a4e395 in __assert_fail_base.cold () from /lib64/libc.so.6
    #4  0x00007ffff7a5cb12 in __assert_fail () from /lib64/libc.so.6
    #5  0x00007ffff73ced3a in read_scaling_list ([email protected]=0x7fffffffd290, [email protected]=0x55555557e3d0, [email protected]=0x55555557e64e, [email protected]=false) at sps.cc:931
    #6  0x00007ffff73d0693 in seq_parameter_set::read ([email protected]=0x55555557e3d0, [email protected]=0x55555557c978, [email protected]=0x7fffffffd290) at sps.cc:350
    #7  0x00007ffff73a914d in decoder_context::read_sps_NAL ([email protected]=0x55555557c970, reader=...) at /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11/bits/shared_ptr_base.h:1295
    #8  0x00007ffff73ab320 in decoder_context::decode_NAL ([email protected]=0x55555557c970, nal=0x55555557c850) at decctx.cc:1248
    #9  0x00007ffff73ab5fe in decoder_context::decode (this=0x55555557c970, more=0x7fffffffd354) at decctx.cc:1327
    #10 0x00007ffff739ff44 in de265_decode (de265ctx=<optimized out>, more=<optimized out>) at de265.cc:352
    #11 0x00007ffff7f760b3 in libde265_v1_decode_image (decoder_raw=0x55555557b850, out_img=0x7fffffffd410) at plugins/heif_decoder_libde265.cc:324
    #12 0x00007ffff7f53e27 in heif::HeifContext::decode_image_planar (this=0x5555555780f0, ID=<optimized out>, img=std::shared_ptr<heif::HeifPixelImage> (empty) = {...},
        [email protected]=heif_colorspace_RGB, [email protected]=0x55555557c8d0, alphaImage=false) at heif_context.cc:1181
    #13 0x00007ffff7f550b3 in heif::HeifContext::decode_image_user (this=<optimized out>, ID=<optimized out>, img=std::shared_ptr<heif::HeifPixelImage> (empty) = {...}, out_colorspace=heif_colorspace_RGB,
        out_chroma=heif_chroma_interleaved_RGB, options=0x55555557c8d0) at heif_context.cc:1088
    #14 0x00007ffff7f42d8e in heif_decode_image (in_handle=0x55555557b9e0, out_img=0x7fffffffd888, colorspace=<optimized out>, chroma=<optimized out>, options=<optimized out>) at heif.cc:946
    #15 0x0000555555559644 in main (argc=<optimized out>, argv=<optimized out>) at heif_convert.cc:329
    
  • Wrong library shared object name when using Cmake build system

    Wrong library shared object name when using Cmake build system

    SO to make the long story short, when I build libde265 from the source using autotools (configure script) it produces a shared object named "libde265.so".

    But! When I'll use cmake build system, the produced shared object name is "liblibde265.so", which makes it undetectable by external projects like ImageMagick: https://github.com/ImageMagick/ImageMagick/issues/5783

  • A Heap-buffer-overflow in motion.cc:1636:46 in derive_spatial_luma_vector_prediction

    A Heap-buffer-overflow in motion.cc:1636:46 in derive_spatial_luma_vector_prediction

    1. Description

    A heap-buffer-overflow has occurred in derive_spatial_luma_vector_prediction(base_context*, de265_image*, slice_segment_header const*, int, int, int, int, int, int, int, int, int, int, unsigned char*, MotionVector*) of libde265/motion.cc:1636:46 when running program build/dec265/dec265, this can reproduce on the lattest commit.

    2. Software version info

    $ git log -1
    commit a1ac9e0f84be3c5030dfea4b484fb9e140c89549 (HEAD -> master, origin/master, origin/HEAD)
    
    $ ./build/dec265/dec265   
     dec265  v1.0.9
    

    3. System version info

    Ubuntu 20.04.2 LTS
    Linux 5.4.0-65-generic
    

    4. Command

    ./build/dec265/dec265 ./poc1
    

    5. Result

    =================================================================
    ==2029365==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61b000000d1c at pc 0x7f0051192b1e bp 0x7ffc4de06e10 sp 0x7ffc4de06e08
    READ of size 4 at 0x61b000000d1c thread T0
        #0 0x7f0051192b1d in derive_spatial_luma_vector_prediction(base_context*, de265_image*, slice_segment_header const*, int, int, int, int, int, int, int, int, int, int, unsigned char*, MotionVector*) /Projects/libde265/libde265/motion.cc:1636:46
        #1 0x7f00511943b5 in fill_luma_motion_vector_predictors(base_context*, slice_segment_header const*, de265_image*, int, int, int, int, int, int, int, int, int, int, MotionVector*) /Projects/libde265/libde265/motion.cc:1905:3
        #2 0x7f00511955a3 in luma_motion_vector_prediction(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int, int, int) /Projects/libde265/libde265/motion.cc:1978:3
        #3 0x7f00511955a3 in motion_vectors_and_ref_indices(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int, PBMotion*) /Projects/libde265/libde265/motion.cc:2062:19
        #4 0x7f0051195c03 in decode_prediction_unit(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int) /Projects/libde265/libde265/motion.cc:2102:3
        #5 0x7f00511dda7d in read_prediction_unit(thread_context*, int, int, int, int, int, int, int, int, int) /Projects/libde265/libde265/slice.cc:4136:3
        #6 0x7f00511df598 in read_coding_unit(thread_context*, int, int, int, int) /Projects/libde265/libde265/slice.cc:4497:9
        #7 0x7f00511e477b in decode_substream(thread_context*, bool, bool) /Projects/libde265/libde265/slice.cc:4741:5
        #8 0x7f00511e7bfd in read_slice_segment_data(thread_context*) /Projects/libde265/libde265/slice.cc:5054:14
        #9 0x7f0051116148 in decoder_context::decode_slice_unit_sequential(image_unit*, slice_unit*) /Projects/libde265/libde265/decctx.cc:852:7
        #10 0x7f0051113e41 in decoder_context::decode_slice_unit_parallel(image_unit*, slice_unit*) /Projects/libde265/libde265/decctx.cc:954:11
        #11 0x7f0051112a26 in decoder_context::decode_some(bool*) /Projects/libde265/libde265/decctx.cc:739:13
        #12 0x7f005110f138 in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) /Projects/libde265/libde265/decctx.cc:697:9
        #13 0x7f0051118774 in decoder_context::decode_NAL(NAL_unit*) /Projects/libde265/libde265/decctx.cc:1239:11
        #14 0x7f0051119145 in decoder_context::decode(int*) /Projects/libde265/libde265/decctx.cc:1327:16
        #15 0x4cede4 in main /Projects/libde265/dec265/dec265.cc:764:17
        #16 0x7f0050b18082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
        #17 0x41e51d in _start (/Projects/libde265/build/dec265/dec265+0x41e51d)
    
    0x61b000000d1c is located 20 bytes to the right of 1416-byte region [0x61b000000780,0x61b000000d08)
    allocated by thread T0 here:
        #0 0x4ca83d in operator new(unsigned long) (/Projects/libde265/build/dec265/dec265+0x4ca83d)
        #1 0x7f005110d9cf in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) /Projects/libde265/libde265/decctx.cc:633:32
        #2 0x7f0051118774 in decoder_context::decode_NAL(NAL_unit*) /Projects/libde265/libde265/decctx.cc:1239:11
        #3 0x7f0051119145 in decoder_context::decode(int*) /Projects/libde265/libde265/decctx.cc:1327:16
        #4 0x4cede4 in main /Projects/libde265/dec265/dec265.cc:764:17
        #5 0x7f0050b18082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow /Projects/libde265/libde265/motion.cc:1636:46 in derive_spatial_luma_vector_prediction(base_context*, de265_image*, slice_segment_header const*, int, int, int, int, int, int, int, int, int, int, unsigned char*, MotionVector*)
    Shadow bytes around the buggy address:
      0x0c367fff8150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c367fff8190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c367fff81a0: 00 fa fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff81b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff81c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff81d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff81e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c367fff81f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07 
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==2029365==ABORTING
    

    6. POC

    Download: POC1

    Report of the Information Security Laboratory of Ocean University of China @OUC_ISLOUC @OUC_Blue_Whale

Related tags
🤟Super fast H.264/H.265 FLV player
🤟Super fast H.264/H.265 FLV player

??Super fast H.264/H.265 FLV player

Dec 7, 2022
Open Source H.264 Codec

OpenH264 OpenH264 is a codec library which supports H.264 encoding and decoding. It is suitable for use in real time applications such as WebRTC. See

Dec 2, 2022
OpenShot Video Library (libopenshot) is a free, open-source C++ library dedicated to delivering high quality video editing, animation, and playback solutions to the world

OpenShot Video Library (libopenshot) is a free, open-source C++ library dedicated to delivering high quality video editing, animation, and playback solutions to the world

Dec 3, 2022
A free, fast, cross-platform volumetric codec for everyone.

The open source Universal Volumetric (".uvol") compressed interchange format for streaming mesh sequences. This project also includes a cross-platform player implementation using h.264 video for texture.

Nov 30, 2022
ffmpeg supporting EVC codec and file formats.

ffevc ffmpeg supporting EVC codec and file formats. MPEG-5 Essential Video Coding (EVC) integration with FFmpeg project. It is supported under Linux a

Nov 23, 2022
Vulkan Video Sample Application demonstrating an end-to-end, all-Vulkan, processing of h.264/5 compressed video content.
Vulkan Video Sample Application demonstrating an end-to-end, all-Vulkan, processing of h.264/5 compressed video content.

This project is a Vulkan Video Sample Application demonstrating an end-to-end, all-Vulkan, processing of h.264/5 compressed video content. The application decodes the h.264/5 compressed content using an HW accelerated decoder, the decoded YCbCr frames are processed with Vulkan Graphics and then presented via the Vulkan WSI.

Dec 7, 2022
Video stabilization is a software-based approach in real-time to eliminating environmental effects (wind, heavy vehicle etc.) and enhance the visual performance that degrade video streaming quality.
Video stabilization is a software-based approach in real-time to eliminating environmental effects (wind, heavy vehicle etc.) and enhance the visual performance that degrade video streaming quality.

Video Stabilization Contents General Info Installation To Do General Info Video stabilization is a software-based approach in real-time to eliminating

Nov 23, 2022
Minimalist video maker -- simplify your music score video making process!

VisualScores 极简视频制作程序,简化你的乐谱视频制作! 如果需要编译,请解压 lib 文件夹中压缩包。 使用前请参考 manual 文件夹中的用户手册。 请勿修改、移动或删除 resource 文件夹中的任何文件。 VisualScores Minimalist video maker

Sep 7, 2022
Shotcut - a free, open source, cross-platform video editor
 Shotcut - a free, open source, cross-platform video editor

cross-platform (Qt), open-source (GPLv3) video editor

Dec 7, 2022
Vireo is a lightweight and versatile video processing library written in C++11

Overview Vireo is a lightweight and versatile video processing library that powers our video transcoding service, deep learning recognition systems an

Dec 8, 2022
Olive is a free non-linear video editor for Windows, macOS, and Linux.
Olive is a free non-linear video editor for Windows, macOS, and Linux.

Olive is a free non-linear video editor for Windows, macOS, and Linux.

Nov 30, 2022
Video player for 3ds
Video player for 3ds

Video player for 3DS Patch note v1.0.1 Added allow skip frames option v1.0.0 Initial release Summary Video player for 3DS Performance 256x144(144p)@30

Nov 21, 2022
Plugin for VLC that pauses/plays video on mouse click

Pause Click plugin for VLC VLC plugin that allows you to pause/play a video by clicking on the video image. Can be configured to work nicely with doub

Nov 29, 2022
A WFH utility to visually indicate user engagement of audio and video
A WFH utility to visually indicate user engagement of audio and video

DIY: In meeting indicator - WFH Utility The need for in meeting indicator at home So many of you have gotten accustomed to work from home by now. This

Jun 28, 2021
Real-Time Intermediate Flow Estimation for Video Frame Interpolation filter for VapourSynth

Description RIFE filter for VapourSynth, based on rife-ncnn-vulkan. Usage rife.RIFE(clip clip[, int model=0, int gpu_id=auto, int gpu_thread=2, bint t

Nov 23, 2022
SRS is a simple, high efficiency and realtime video server, supports RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB28181.
SRS is a simple, high efficiency and realtime video server, supports RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB28181.

SRS is a simple, high efficiency and realtime video server, supports RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB28181.

Dec 5, 2022
Anki-like app for spaced repetition of video clips
Anki-like app for spaced repetition of video clips

ReeePlayer The ReeePlayer application is designed for spaced repetition of fragments (clips) of video and audio files with similar principle as in Ank

Oct 28, 2022
NymphCast is a audio and video casting system with support for custom applications.
NymphCast is a audio and video casting system with support for custom applications.

NymphCast is a software solution which turns your choice of Linux-capable hardware into an audio and video source for a television or powered speakers. It enables the streaming of audio and video over the network from a wide range of client devices, as well as the streaming of internet media to a NymphCast server, controlled by a client device.

Dec 1, 2022
SortNode is a JS binding for SORT: Simple, online, and real-time tracking of multiple objects in a video sequence.

SortNode is a JS binding for SORT: Simple, online, and real-time tracking of multiple objects in a video sequence.

Aug 2, 2022