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 http://www.openh264.org/ for more details.

Encoder Features

  • Constrained Baseline Profile up to Level 5.2 (Max frame size is 36864 macro-blocks)
  • Arbitrary resolution, not constrained to multiples of 16x16
  • Rate control with adaptive quantization, or constant quantization
  • Slice options: 1 slice per frame, N slices per frame, N macroblocks per slice, or N bytes per slice
  • Multiple threads automatically used for multiple slices
  • Temporal scalability up to 4 layers in a dyadic hierarchy
  • Simulcast AVC up to 4 resolutions from a single input
  • Spatial simulcast up to 4 resolutions from a single input
  • Long Term Reference (LTR) frames
  • Memory Management Control Operation (MMCO)
  • Reference picture list modification
  • Single reference frame for inter prediction
  • Multiple reference frames when using LTR and/or 3-4 temporal layers
  • Periodic and on-demand Instantaneous Decoder Refresh (IDR) frame insertion
  • Dynamic changes to bit rate, frame rate, and resolution
  • Annex B byte stream output
  • YUV 4:2:0 planar input

Decoder Features

  • Constrained Baseline Profile up to Level 5.2 (Max frame size is 36864 macro-blocks)
  • Arbitrary resolution, not constrained to multiples of 16x16
  • Single thread for all slices
  • Long Term Reference (LTR) frames
  • Memory Management Control Operation (MMCO)
  • Reference picture list modification
  • Multiple reference frames when specified in Sequence Parameter Set (SPS)
  • Annex B byte stream input
  • YUV 4:2:0 planar output

OS Support

  • Windows 64-bit and 32-bit
  • Mac OS X 64-bit and 32-bit
  • Linux 64-bit and 32-bit
  • Android 64-bit and 32-bit
  • iOS 64-bit and 32-bit
  • Windows Phone 32-bit

Processor Support

  • Intel x86 optionally with MMX/SSE (no AVX yet, help is welcome)
  • ARMv7 optionally with NEON, AArch64 optionally with NEON
  • Any architecture using C/C++ fallback functions

Building the Library

NASM needed to be installed for assembly code: workable version 2.10.06 or above, NASM can downloaded from http://www.nasm.us/. For Mac OSX 64-bit NASM needed to be below version 2.11.08 as NASM 2.11.08 will introduce error when using RIP-relative addresses in Mac OSX 64-bit

To build the arm assembly for Windows Phone, gas-preprocessor is required. It can be downloaded from git://git.libav.org/gas-preprocessor.git

For Android Builds

To build for android platform, You need to install android sdk and ndk. You also need to export **ANDROID_SDK**/tools to PATH. On Linux, this can be done by

export PATH=**ANDROID_SDK**/tools:$PATH

The codec and demo can be built by

make OS=android NDKROOT=**ANDROID_NDK** TARGET=**ANDROID_TARGET**

Valid **ANDROID_TARGET** can be found in **ANDROID_SDK**/platforms, such as android-12. You can also set ARCH, NDKLEVEL according to your device and NDK version. ARCH specifies the architecture of android device. Currently arm, arm64, x86 and x86_64 are supported, the default is arm. (mips and mips64 can also be used, but there's no specific optimization for those architectures.) NDKLEVEL specifies android api level, the default is 12. Available possibilities can be found in **ANDROID_NDK**/platforms, such as android-21 (strip away the android- prefix).

By default these commands build for the armeabi-v7a ABI. To build for the other android ABIs, add ARCH=arm64, ARCH=x86, ARCH=x86_64, ARCH=mips or ARCH=mips64. To build for the older armeabi ABI (which has armv5te as baseline), add APP_ABI=armeabi (ARCH=arm is implicit). To build for 64-bit ABI, such as arm64, explicitly set NDKLEVEL to 21 or higher.

For iOS Builds

You can build the libraries and demo applications using xcode project files located in codec/build/iOS/dec and codec/build/iOS/enc.

You can also build the libraries (but not the demo applications) using the make based build system from the command line. Build with

make OS=ios ARCH=**ARCH**

Valid values for **ARCH** are the normal iOS architecture names such as armv7, armv7s, arm64, and i386 and x86_64 for the simulator. Another settable iOS specific parameter is SDK_MIN, specifying the minimum deployment target for the built library. For other details on building using make on the command line, see 'For All Platforms' below.

For Linux Builds

You can build the libraries (but not the demo applications) using the make based build system from the command line. Build with

make OS=linux ARCH=**ARCH**

You can set ARCH according to your linux device . ARCH specifies the architecture of the device. Currently arm, arm64, x86 and x86_64 are supported

NOTICE: If your computer is x86 architecture, for build the libnary which be used on arm/aarch64 machine, you may need to use cross-compiler, for example: make OS=linux CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ ARCH=arm64 or make OS=linux CC=arm-linux-gnueabi-gcc CXX=arm-linux-gnueabi-g++ ARCH=arm

For Windows Builds

Our Windows builds use MinGW which can be downloaded from http://www.mingw.org/

To build with gcc, add the MinGW bin directory (e.g. /c/MinGW/bin) to your path and follow the 'For All Platforms' instructions below.

To build with Visual Studio you will need to set up your path to run cl.exe. The easiest way is to start MSYS from a developer command line session. Instructions can be found at http://msdn.microsoft.com/en-us/library/ms229859(v=vs.110).aspx. If you need to do it by hand here is an example from a Windows 64bit install of VS2012:

export PATH="$PATH:/c/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin:/c/Program Files (x86)/Microsoft Visual Studio 11.0/Common7/IDE"

You will also need to set your INCLUDE and LIB paths to point to your VS and SDK installs. Something like this, again from Win64 with VS2012 (note the use of Windows-style paths here).

export INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include;C:\Program Files (x86)\Windows Kits\8.0\Include\um;C:\Program Files (x86)\Windows Kits\8.0\Include\shared"
export LIB="C:\Program Files (x86)\Windows Kits\8.0\Lib\Win8\um\x86;C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib"

Then add OS=msvc to the make line of the 'For All Platforms' instructions.

For Windows Phone Builds

Follow the instructions above for normal Windows builds, but use OS=msvc-wp instead of OS=msvc. You will also need gas-preprocessor (as mentioned below "Building the Library").

If building for Windows Phone with MSVC 2013, there's no included bat file that sets the lib paths to the Windows Phone kit, but that can be done with a command like this:

export LIB="c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\store\arm;c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\arm;c:\Program Files (x86)\Windows Phone Kits\8.1\lib\arm"

This is only necessary for building the DLL; the static library can be built without setting this.

Note, only Windows Phone 8.1 or newer is supported, 8.0 is no longer supported.

For All Platforms

Using make

From the main project directory:

  • make for automatically detecting architecture and building accordingly
  • make ARCH=i386 for x86 32-bit builds
  • make ARCH=x86_64 for x86 64-bit builds
  • make V=No for a silent build (not showing the actual compiler commands)
  • make DEBUGSYMBOLS=True for two libraries, one is normal libraries, another one is removed the debugging symbol table entries (those created by the -g option)

The command line programs h264enc and h264dec will appear in the main project directory.

A shell script to run the command-line apps is in testbin/CmdLineExample.sh

Usage information can be found in testbin/CmdLineReadMe

Using meson

Meson build definitions have been added, and are known to work on Linux and Windows, for x86 and x86 64-bit.

See http://mesonbuild.com/Installing.html for instructions on how to install meson, then:

meson builddir
ninja -C builddir

Run the tests with:

meson test -C builddir -v

Install with:

ninja -C builddir install

Using the Source

  • codec - encoder, decoder, console (test app), build (makefile, vcproj)
  • build - scripts for Makefile build system
  • test - GTest unittest files
  • testbin - autobuild scripts, test app config files
  • res - yuv and bitstream test files

Known Issues

See the issue tracker on https://github.com/cisco/openh264/issues

  • Encoder errors when resolution exceeds 3840x2160
  • Encoder errors when compressed frame size exceeds half uncompressed size
  • Decoder errors when compressed frame size exceeds 1MB
  • Encoder RC requires frame skipping to be enabled to hit the target bitrate, if frame skipping is disabled the target bitrate may be exceeded

License

BSD, see LICENSE file for details.

Owner
Cisco Systems
Open Source Projects from Cisco Systems
Cisco Systems
Comments
  • x86 library has text relocations, can't be used on Android 6

    x86 library has text relocations, can't be used on Android 6

    When compiling openH264 for Android x86 using make libraries -j4 OS=android ARCH=x86 NDKROOT=$(NDK_PATH) TARGET=android-19

    The generated libopenh264.so has text relocation issue that causes Android 6 to crash when trying to load it. You can check using: readelf -d -r libopenh264.so | grep TEXT

    I've tried with commit id 21ad38f430f62d11ff0c02f245a1df904f89f99a, and I'm using NDK r10e-rc4 on Linux 64bits.

  • Makefile, pkg-config: Add INCLUDE_PREFIX variable, use include/openh2…

    Makefile, pkg-config: Add INCLUDE_PREFIX variable, use include/openh2…

    Makefile, pkg-config:

    Add INCLUDE_PREFIX variable, use $(PREFIX)/include/openh264 as default, include correct default in the pkg-config file

    People who use the pkg-config mechanism will benefit from this immediately and may not have to make any local changes to their own code.

    People who hardcoded the paths may need to start using pkg-config or tweak their paths as they prefer.

  • Reintroduced Frame-Order bug in master/v2.2.0

    Reintroduced Frame-Order bug in master/v2.2.0

    Bug reported in https://github.com/cisco/openh264/issues/3305 has been reintroduced in master and https://github.com/cisco/openh264/tree/v2.2.0

    Offending commit: dc17ceea7aae76131e30d72c69f801185e917b05

    Easy way to test:

    1. Compile FreeRDP from https://github.com/FreeRDP/FreeRDP/tree/master with cmake -GNinja -DWITH_OPENH264=ON
    2. Connect to some windows RDP server with xfreerdp /v:someserver (AVC mode enabled)
    3. Create a selection rectangle with a mouse left click
    4. Release the rectangle
    5. See that the rectangle is (in part) still visible

    To verify the stream can be decoded properly:

    1. Compile FreeRDP from https://github.com/FreeRDP/FreeRDP/tree/master with cmake -GNinja -DWITH_FFMPEG=ON
    2. Retry above
  • x264 encoding + openh264 decoding = decoding bitstream errors?

    x264 encoding + openh264 decoding = decoding bitstream errors?

    I'm using wirecast to encode a screen capture via x264 (@ 480p, 30fps, keyframes every 1 second, baseline profile). I have an application which decodes using openh264. About every 2-10 seconds I get about 10-30 frames of chain decoding errors every frame. It usually starts with a bitstream error.

    x264 has many encoding options. I'm assuming it is encoding in a way openh264 doesn't support, but perhaps there is an option I can turn off to make openh264 decode properly. Does anyone have a clue as to what I should attempt to disable in order to have openh264 decode without errors?

    Here's the error I get:

    [OpenH264] this = 0x0x7fb7d9736ac0, Warning:invalid syntax vertical mv 23913
    [OpenH264] this = 0x0x7fb7d9736ac0, Warning:DecodeCurrentAccessUnit() failed (1035) in frame: 3 uiDId: 0 uiQId: 0
    [OpenH264] this = 0x0x7fb7d9736ac0, Info:decode failed, failure type:36 
    

    Note: when I turn on error concealment it does an okay job at concealing this problem, but I still get visual artifacts, depending on the data, every 30s or so.

  • Get rid of the OpenSSL dependency by bundling a simple SHA1 implementation

    Get rid of the OpenSSL dependency by bundling a simple SHA1 implementation

    The SHA1 implementation is taken from RFC 3174, and the license should be compatible as far as I can see, and nothing of it gets included in actual distributed binaries of OpenH264 anyway.

    The whole replacement process is split into a few small, easily readable commits.

  • Please either add source, or remove this project

    Please either add source, or remove this project

    It is embarrassing for Cisco, and a bit insulting to those of us who work in Open Source, to call this project "Open Source", and not actually have any source code in it. Rather than getting any goodwill from announcing your intent to share the code of your H.264 implementation, you will likely find that the community will react with scorn and derision.

    I recommend removing this project from Github until the source code IS available. I understand that it takes time to do this for various legal and organizational reasons, but jumping the gun, and releasing a project that doesn't have any source code, and calling it "Open Source", is insulting to our intelligence, our hard work, and it incurs a dramatic credibility cost for Cisco with the very people that I presume you're trying to befriend.

    Please. Don't do this. Don't go down this tired BigDumbCorp road. Take this empty thing down, or add the source code. It's offensive and insulting, and the internet is already descending on you with jokes and jibes. If the goal is marketing, then this is absolutely the wrong way to go about it.

  • meson: Use pkg-config generator and some cleanups

    meson: Use pkg-config generator and some cleanups

    When using library() instead of shared_library() and static_library, meson will build shared, static, or both depending on the value of static_library option.

    As far as I know extract_all_objects() was uses as workaround for Meson bugs fixed a while ago when using not installed static libraries.

  • Very different compressed file sizes when using 2 slices vs. 1 slice.

    Very different compressed file sizes when using 2 slices vs. 1 slice.

    I am using openh264 (current master) with FFmpeg. With all other parameters the same, the compressed file size is radically different depending on the number of slices specified, and whether or not load balancing is on:

              load     compressed
    slices  balancing  file size
    ------  ---------  ----------
      1        N/A      2,880,193
      2        on       4,777,473
      2        off     19,301,756
    

    There are two unexpected results here:

    (1) Why is the 2-slice-with-load-balancing output 66% bigger than the 1-slice output?

    (2) Why is the 2-slice-without-load-balancing output 4 times bigger than the 2-slice-with-load-balancing output?

    I also have an implementation of SSIM that I use to measure the output compressed video quality vs. the original losslessly compressed video. The SSIM numbers correlate with the compressed file sizes, with the largest file having the highest quality (as expected).

    For these test runs I have set the bit rates to be very high, equal to the bit rate needed for uncompressed YUV 420 video.

    If this is not a bug, then I would like to know how to set the compression parameters so that I get similar output file sizes from all three cases. In particular, I am wondering if I need to set iMinQp and iMaxQp?

    Below is diagnostic output showing some of the compression parameters:

    1 slice:

    Info:CWelsH264SVCEncoder::SetOption(), openh264 codec version = .
    Info:CWelsH264SVCEncoder::InitEncoder(), openh264 codec version = 
    Info:iUsageType = 0,iPicWidth= 1920;iPicHeight= 1080;iTargetBitrate= 597196800;iMaxBitrate= 597196800;iRCMode= 0;iPaddingFlag= 0;iTemporalLayerNum= 1;iSpatialLayerNum= 1;fFrameRate= 24.000000f;uiIntraPeriod= 96;eSpsPpsIdStrategy = 0;bPrefixNalAddingCtrl = 0;bSimulcastAVC=0;bEnableDenoise= 0;bEnableBackgroundDetection= 1;bEnableSceneChangeDetect = 1;bEnableAdaptiveQuant= 1;bEnableFrameSkip= 0;bEnableLongTermReference= 0;iLtrMarkPeriod= 30;iComplexityMode = 1;iNumRefFrame = 1;iEntropyCodingModeFlag = 0;uiMaxNalSize = 0;iLTRRefNum = 0;iMultipleThreadIdc = 1;iLoopFilterDisableIdc = 0 (offset(alpha/beta): 0,0;iMaxQp = 51;iMinQp = 0)
    Info:sSpatialLayers[0]: .iVideoWidth= 1920; .iVideoHeight= 1088; .fFrameRate= 24.000000f; .iSpatialBitrate= 597196800; .iMaxSpatialBitrate= 0; .sSliceArgument.uiSliceMode= 1; .sSliceArgument.iSliceNum= 1; .sSliceArgument.uiSliceSizeConstraint= 1500;uiProfileIdc = 66;uiLevelIdc = 0
    Info:SliceArgumentValidationFixedSliceMode(), uiSliceNum(1) you set for SM_FIXEDSLCNUM_SLICE, now turn to SM_SINGLE_SLICE type!
    Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame.
    Info:WELS CPU features/capacities (0x4007fe3f) detected:    HTT:      Y, MMX:      Y, MMXEX:    Y, SSE:      Y, SSE2:     Y, SSE3:     Y, SSSE3:    Y, SSE4.1:   Y, SSE4.2:   Y, AVX:      Y, FMA:      Y, X87-FPU:  Y, 3DNOW:    N, 3DNOWEX:  N, ALTIVEC:  N, CMOV:     Y, MOVBE:    Y, AES:      Y, NUMBER OF LOGIC PROCESSORS ON CHIP: 8, CPU CACHE LINE SIZE (BYTES):        64
    Info:WelsInitEncoderExt() exit, overall memory usage: 26749630 bytes
    Info:CWelsH264SVCEncoder::~CWelsH264SVCEncoder()
    Info:CWelsH264SVCEncoder::Uninitialize(), openh264 codec version = .
    Info:WelsUninitEncoderExt(), pCtx= 04810fc8, iMultipleThreadIdc= 1.
    Info:FreeMemorySvc(), verify memory usage (0 bytes) after free..
    

    2 slices, load balancing on:

    Info:CWelsH264SVCEncoder::SetOption(), openh264 codec version = .
    Info:CWelsH264SVCEncoder::InitEncoder(), openh264 codec version = 
    Info:iUsageType = 0,iPicWidth= 1920;iPicHeight= 1080;iTargetBitrate= 597196800;iMaxBitrate= 597196800;iRCMode= 0;iPaddingFlag= 0;iTemporalLayerNum= 1;iSpatialLayerNum= 1;fFrameRate= 24.000000f;uiIntraPeriod= 96;eSpsPpsIdStrategy = 0;bPrefixNalAddingCtrl = 0;bSimulcastAVC=0;bEnableDenoise= 0;bEnableBackgroundDetection= 1;bEnableSceneChangeDetect = 1;bEnableAdaptiveQuant= 1;bEnableFrameSkip= 0;bEnableLongTermReference= 0;iLtrMarkPeriod= 30;iComplexityMode = 1;iNumRefFrame = 1;iEntropyCodingModeFlag = 0;uiMaxNalSize = 0;iLTRRefNum = 0;iMultipleThreadIdc = 2;iLoopFilterDisableIdc = 0 (offset(alpha/beta): 0,0;iMaxQp = 51;iMinQp = 0)
    Info:sSpatialLayers[0]: .iVideoWidth= 1920; .iVideoHeight= 1088; .fFrameRate= 24.000000f; .iSpatialBitrate= 597196800; .iMaxSpatialBitrate= 0; .sSliceArgument.uiSliceMode= 1; .sSliceArgument.iSliceNum= 2; .sSliceArgument.uiSliceSizeConstraint= 1500;uiProfileIdc = 66;uiLevelIdc = 0
    Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame.
    Info:WELS CPU features/capacities (0x4007fe3f) detected:    HTT:      Y, MMX:      Y, MMXEX:    Y, SSE:      Y, SSE2:     Y, SSE3:     Y, SSSE3:    Y, SSE4.1:   Y, SSE4.2:   Y, AVX:      Y, FMA:      Y, X87-FPU:  Y, 3DNOW:    N, 3DNOWEX:  N, ALTIVEC:  N, CMOV:     Y, MOVBE:    Y, AES:      Y, NUMBER OF LOGIC PROCESSORS ON CHIP: 8, CPU CACHE LINE SIZE (BYTES):        64
    Info:WelsInitEncoderExt() exit, overall memory usage: 39296476 bytes
    Info:CWelsH264SVCEncoder::~CWelsH264SVCEncoder()
    Info:CWelsH264SVCEncoder::Uninitialize(), openh264 codec version = .
    Info:WelsUninitEncoderExt(), pCtx= 047c0fc8, iMultipleThreadIdc= 2.
    Info:FreeMemorySvc(), verify memory usage (0 bytes) after free..
    

    2 slices, load balancing off:

    Info:CWelsH264SVCEncoder::SetOption(), openh264 codec version = .
    Info:CWelsH264SVCEncoder::InitEncoder(), openh264 codec version = 
    Info:iUsageType = 0,iPicWidth= 1920;iPicHeight= 1080;iTargetBitrate= 597196800;iMaxBitrate= 597196800;iRCMode= 0;iPaddingFlag= 0;iTemporalLayerNum= 1;iSpatialLayerNum= 1;fFrameRate= 24.000000f;uiIntraPeriod= 96;eSpsPpsIdStrategy = 0;bPrefixNalAddingCtrl = 0;bSimulcastAVC=0;bEnableDenoise= 0;bEnableBackgroundDetection= 1;bEnableSceneChangeDetect = 1;bEnableAdaptiveQuant= 1;bEnableFrameSkip= 0;bEnableLongTermReference= 0;iLtrMarkPeriod= 30;iComplexityMode = 1;iNumRefFrame = 1;iEntropyCodingModeFlag = 0;uiMaxNalSize = 0;iLTRRefNum = 0;iMultipleThreadIdc = 2;iLoopFilterDisableIdc = 0 (offset(alpha/beta): 0,0;iMaxQp = 51;iMinQp = 0)
    Info:sSpatialLayers[0]: .iVideoWidth= 1920; .iVideoHeight= 1088; .fFrameRate= 24.000000f; .iSpatialBitrate= 597196800; .iMaxSpatialBitrate= 0; .sSliceArgument.uiSliceMode= 1; .sSliceArgument.iSliceNum= 2; .sSliceArgument.uiSliceSizeConstraint= 1500;uiProfileIdc = 66;uiLevelIdc = 0
    Warning:bEnableFrameSkip = 0,bitrate can't be controlled for RC_QUALITY_MODE,RC_BITRATE_MODE and RC_TIMESTAMP_MODE without enabling skip frame.
    Info:WELS CPU features/capacities (0x4007fe3f) detected:    HTT:      Y, MMX:      Y, MMXEX:    Y, SSE:      Y, SSE2:     Y, SSE3:     Y, SSSE3:    Y, SSE4.1:   Y, SSE4.2:   Y, AVX:      Y, FMA:      Y, X87-FPU:  Y, 3DNOW:    N, 3DNOWEX:  N, ALTIVEC:  N, CMOV:     Y, MOVBE:    Y, AES:      Y, NUMBER OF LOGIC PROCESSORS ON CHIP: 8, CPU CACHE LINE SIZE (BYTES):        64
    Info:WelsInitEncoderExt() exit, overall memory usage: 39296476 bytes
    Info:CWelsH264SVCEncoder::~CWelsH264SVCEncoder()
    Info:CWelsH264SVCEncoder::Uninitialize(), openh264 codec version = .
    Info:WelsUninitEncoderExt(), pCtx= 047d0fc8, iMultipleThreadIdc= 2.
    Info:FreeMemorySvc(), verify memory usage (0 bytes) after free..
    
  • Serious bug in version 1.6

    Serious bug in version 1.6

    Version 1.6 encoder has a serious bug. Using following parameters to encode will produce illformed bitstream; when decoding, it will trigger errors in CheckIntra16x16PredMode.

    pPtrEnc->GetDefaultParams (&sSvcParam); sParam.iUsageType = CAMERA_VIDEO_REAL_TIME; sParam.fMaxFrameRate = 30.0f; // input frame rate sParam.iPicWidth = 1280; // width of picture in samples sParam.iPicHeight = 720; // height of picture in samples sParam.iTargetBitrate = 200000; // target bitrate desired sParam.iMaxBitrate = UNSPECIFIED_BIT_RATE; sParam.iRCMode = RC_TIMESTAMP_MODE; // rc mode control sParam.iTemporalLayerNum = 1; // layer number at temporal level sParam.iSpatialLayerNum = 1; // layer number at spatial level sParam.bEnableDenoise = 0; // denoise control sParam.bEnableBackgroundDetection = 1; // background detection control sParam.bEnableAdaptiveQuant = 1; // adaptive quantization control sParam.bEnableFrameSkip = 1; // frame skipping sParam.bEnableLongTermReference = 0; // long term reference control sParam.iLtrMarkPeriod = 30; sParam.uiIntraPeriod = 0; // period of Intra frame sParam.eSpsPpsIdStrategy = INCREASING_ID; sParam.bPrefixNalAddingCtrl = 0; sParam.iComplexityMode = MEDIUM_COMPLEXITY; sParam.bSimulcastAVC = true; int iIndexLayer = 0; sParam.sSpatialLayers[iIndexLayer].uiProfileIdc = PRO_BASELINE; sParam.sSpatialLayers[iIndexLayer].iVideoWidth = 1280; sParam.sSpatialLayers[iIndexLayer].iVideoHeight = 720; sParam.sSpatialLayers[iIndexLayer].fFrameRate = 30.0f; sParam.sSpatialLayers[iIndexLayer].iSpatialBitrate = 200000; sParam.sSpatialLayers[iIndexLayer].iMaxSpatialBitrate = UNSPECIFIED_BIT_RATE; sParam.sSpatialLayers[iIndexLayer].sSliceArgument.uiSliceMode = SM_FIXEDSLCNUM_SLICE; sParam.iMultipleThreadIdc = 2;

    There are three key parameters related to this problem.

    1. sParam.bEnableFrameSkip must be enabled;
    2. sParam.iMultipleThreadIdc = 2 must be multithreaded
    3. sParam.iTargetBitrate = 200000; sParam.sSpatialLayers[iIndexLayer].iSpatialBitrate = 200000; bitrate should be small to enough to trigger frame skip.
  • build fail for android on linux

    build fail for android on linux

    I want to use openh264 with ffmpeg for android app. I tried to build openh264 for android by below command. make OS=android NDKROOT=~/Android/android-ndk-r18b TARGET=android-28 NDKLEVEL=28

    but I failed with this error message. ysroot=/home/cheolhwi/Android/android-ndk-r18b/platforms/android-28/arch-arm -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-soname,libopenh264.so /usr/bin/ld: unrecognised emulation mode: armelf_linux_eabi Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu i386linux elf_l1om elf_k1om i386pep i386pe clang++: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:240: recipe for target 'libopenh264.so' failed make: *** [libopenh264.so] Error 1

    I think that it failed by usage of wrong ld(/usr/bin/ld). Is it right? Please help me if someone has any idea.

  • OPEN H264 SVC

    OPEN H264 SVC

    Hi Team, I ám new to open h264 org and i have downloaded source code in to Linux machine and tried test/sample examples apps, when i decode the h264 svc encoded contents, decoder was throwing following error.

    command to encode: ../h264enc welsenc_vd_1d.cfg

    #layers defination(All are spatial sampling) PrefixNALAddingCtrl 1
    NumLayers 3 # Number of layers LayerCfg layer2.cfg # Layer 0 configuration file LayerCfg layer2_vd_rc.cfg # Layer 1 configuration file LayerCfg layer2_vd.cfg # Layer 2 configuration file

    [OpenH264] this = 0x0x1a5f040, Warning:UpdateAccessUnit():::::Key frame lost.....CAN NOT find IDR from current AU. [OpenH264] this = 0x0x1a5f040, Warning:UpdateAccessUnit():::::Key frame lost.....CAN NOT find IDR from current AU. [OpenH264] this = 0x0x1a5f040, Warning:UpdateAccessUnit():::::Key frame lost.....CAN NOT find IDR from current AU.

    I am actually looking in to H264 SVC funtionality and as a server, stream less bandwidth layer to client who is on bad network. Please provide me

    1. document or link which describes how to link openh264 binary in to my project.
    2. param's required to set at encoder side for SVC support.
    3. How to extract SVC layers.
  • Improve checking for GCC >= 8 and Clang for passing -Wno-class-memaccess

    Improve checking for GCC >= 8 and Clang for passing -Wno-class-memaccess

    Don't pass -Wno-class-memaccess to Clang, which doesn't support that option name. (When inspecting $(CXX) with a pattern, "clang++" also matches the pattern "%g++".)

    Simplify the pattern checking; use $(filter %g++,$(CXX)) instead of $(patsubst %g++,,$(CXX)) making it less obscure. (This requires changing the ifeq ($(),) into ifneq.)

    Check for %clang++ in addition to %g++.

    Also use a similar pattern for checking for clang++ instead of plain exact matches for "clang++", for passing the option -Wc++11-compat-reserved-user-defined-literal - this allows applying the option when CXX contains a path, or if "clang++" is prefixed by a cross triple.

  • Release notes - include glibc version for binary

    Release notes - include glibc version for binary

    I just spent many hours trying to debug why my ffmpeg build would not work, finally ending up on this - debian bullseye does not have a glibc version that would match the openh264.so in its package repositories. The latest openh264 requires glibc 2.34, but the os ships with glibc 2.31. This could've been avoided if I knew about the required glibc version ahead of time.

    It'd be swell if you included the version of glibc the binary was built with in the release notes.

    I think it'd make life easier for integrators (e. g. #2347) and it only takes one line :)

  • Decode key frame but get dsRefLost + dsNoParamSets error

    Decode key frame but get dsRefLost + dsNoParamSets error

    Hi:

    When I decode a video frame, it works fine by ffmpeg.

    However, with openh264, it deocde failed when, e.g. start to decode from 2nd key frame.

    The report error is dsRefLost + dsNoParamSets From the NALU information, the 1st key has (1)SPS + (2)PPS + (3)IDR. However, the 2nd key frame(where issue happens when start decode from there) has (1)SPS, (2)PPS, (3)SEI, (4)code slice. (no IDR NALU)

    I wonder if it is the root cause which lead to decode from 2nd key frame fails?

    If so, is there any setting to avoid such error?

    Or I need to change the NALU label to have openh264 work?

      0th : PTS =         0 us, size =  19633,     key, NRI  3, NALUs = SPS, PPS, IDR, 
      1th : PTS =     83422 us, size =   8690, non-key, NRI  2, NALUs = code slice, 
      2th : PTS =     41711 us, size =   3316, non-key, NRI  0, NALUs = code slice, 
      3th : PTS =    166833 us, size =  10572, non-key, NRI  2, NALUs = code slice, 
      4th : PTS =    125122 us, size =   6364, non-key, NRI  0, NALUs = code slice, 
      5th : PTS =    208544 us, size =  11369, non-key, NRI  2, NALUs = code slice, 
      6th : PTS =    291955 us, size =  12820, non-key, NRI  2, NALUs = code slice, 
      7th : PTS =    250255 us, size =   5175, non-key, NRI  0, NALUs = code slice, 
    ...
     58th : PTS =   2377377 us, size =   3231, non-key, NRI  0, NALUs = code slice, 
     59th : PTS =   2460788 us, size =   4075, non-key, NRI  2, NALUs = code slice, 
     60th : PTS =   2502500 us, size =  22296,     key, NRI  3, NALUs = SPS, PPS, SEI, code slice, 
     61th : PTS =   2585922 us, size =  10693, non-key, NRI  2, NALUs = code slice, 
     62th : PTS =   2544211 us, size =   4995, non-key, NRI  0, NALUs = code slice, 
     63th : PTS =   2669333 us, size =  10940, non-key, NRI  2, NALUs = code slice,
    
  • Add unit test for IdctResAddPred8x8_c/lsx

    Add unit test for IdctResAddPred8x8_c/lsx

    The meson test -C builddir -v outputs on LoongArch:

    [----------] 5 tests from DecoderDecodeMbAux [ RUN ] DecoderDecodeMbAux.IdctResAddPred_c [ OK ] DecoderDecodeMbAux.IdctResAddPred_c (1 ms) [ RUN ] DecoderDecodeMbAux.IdctResAddPred_lsx [ OK ] DecoderDecodeMbAux.IdctResAddPred_lsx (1 ms) [ RUN ] DecoderDecodeMbAux.WelsNonZeroCount_c [ OK ] DecoderDecodeMbAux.WelsNonZeroCount_c (0 ms) [ RUN ] DecoderDecodeMbAux.IdctResAddPred8x8_c [ OK ] DecoderDecodeMbAux.IdctResAddPred8x8_c (8 ms) [ RUN ] DecoderDecodeMbAux.IdctResAddPred8x8_lsx [ OK ] DecoderDecodeMbAux.IdctResAddPred8x8_lsx (6 ms) [----------] 5 tests from DecoderDecodeMbAux (16 ms total)

  • Visual artifacts when encoding

    Visual artifacts when encoding

    using libopenh264 with ffmpeg (master-latest), there appears to be visual artifacts in some cases. I managed to create minimal reproducible example as following:

    ffmpeg -filter_complex "color=black:100x50:60:4[b];movie=img.jpg[i];[b][i]overlay=x=n" -vcodec libopenh264 -y out.mp4
    

    The img.jpg is being animated to the right over the black background. The resulting video contains visual artifacts (1x1 px dots) as demonstrated in artifact.jpg

    This has something to do with p/i frames. As I decrease gop size to -g 10 the artifacts are not visible anymore.

    I have tried other encoders (like x264) and no artifacts appears visible so I guess the issue exists with libopenh264.

    img.jpg artifact.jpg

    https://user-images.githubusercontent.com/750041/199944508-faa8b423-39a1-40ec-b3af-7d1c8001f470.mp4

Related tags
Sentry-Picam is a simple wildlife / security camera solution for the Raspberry Pi Zero W, providing 1080p/30fps motion activated H.264 video capture.
Sentry-Picam is a simple wildlife / security camera solution for the Raspberry Pi Zero W, providing 1080p/30fps motion activated H.264 video capture.

Sentry-Picam is a simple wildlife / security camera solution for the Raspberry Pi Zero W, providing 1080p/30fps motion activated H.264 video capture.

Oct 9, 2022
🤟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 h.265 video codec implementation.
Open h.265 video codec implementation.

libde265 - open h.265 codec implementation libde265 is an open source implementation of the h.265 video codec. It is written from scratch and has a pl

Nov 30, 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
An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support
An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support

Vita-Media-Player An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support 1080i output supported on the PSTV natively and on the

Nov 25, 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
Kodi is an award-winning free and open source software media player and entertainment hub for digital media
Kodi is an award-winning free and open source software media player and entertainment hub for digital media

website • docs • community • add-ons Welcome to Kodi Home Theater Software! Kodi is an award-winning free and open source software media player and en

Dec 1, 2022
GStreamer open-source multimedia framework

GStreamer open-source multimedia framework

Nov 30, 2022
Free and open-source media player written in C++

Liquid Media Player Free and open-source media player written in C++. Currently in development. Build Guide Windows Install the MSYS2 Building Platfor

Sep 20, 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
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
Sentry-Picam is a simple wildlife / security camera solution for the Raspberry Pi Zero W, providing 1080p/30fps motion activated H.264 video capture.
Sentry-Picam is a simple wildlife / security camera solution for the Raspberry Pi Zero W, providing 1080p/30fps motion activated H.264 video capture.

Sentry-Picam is a simple wildlife / security camera solution for the Raspberry Pi Zero W, providing 1080p/30fps motion activated H.264 video capture.

Oct 9, 2022
🤟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 h.265 video codec implementation.
Open h.265 video codec implementation.

libde265 - open h.265 codec implementation libde265 is an open source implementation of the h.265 video codec. It is written from scratch and has a pl

Nov 30, 2022
Simple Binary Encoding (SBE) - High Performance Message Codec

Simple Binary Encoding (SBE) SBE is an OSI layer 6 presentation for encoding and decoding binary application messages for low-latency financial applic

Nov 30, 2022
hessian2-codec it is a complete C++ implementation of hessian2 spec

hessian2-codec is a C++ library from Alibaba for hessian2 codec. It is a complete C++ implementation of hessian2 spec. Because it was originally intended to implement the Dubbo Filter of Envoy, it did not provide good support for serialization of user-defined types (there is only one way to implement user-defined types using ADL, but it is not very complete and does not support nested types well). At the moment it is simply deserializing content into some C++ intermediate types.

Nov 15, 2022
Lossless data compression codec with LZMA-like ratios but 1.5x-8x faster decompression speed, C/C++

LZHAM - Lossless Data Compression Codec Public Domain (see LICENSE) LZHAM is a lossless data compression codec written in C/C++ (specifically C++03),

Dec 7, 2022
Lyra: a generative low bitrate speech codec

Lyra is a high-quality, low-bitrate speech codec that makes voice communication available even on the slowest networks.

Dec 4, 2022
A bespoke sample compression codec for 64k intros
A bespoke sample compression codec for 64k intros

pulsejet A bespoke sample compression codec for 64K intros codec pulsejet lifts a lot of ideas from Opus, and more specifically, its CELT layer, which

Jul 25, 2022