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.

Build Status

libopenshot CI Build libopenshot-audio CI Build


  • Cross-Platform (Linux, Mac, and Windows)
  • Multi-Layer Compositing
  • Video and Audio Effects (Chroma Key, Color Adjustment, Grayscale, etc…)
  • Animation Curves (Bézier, Linear, Constant)
  • Time Mapping (Curve-based Slow Down, Speed Up, Reverse)
  • Audio Mixing & Resampling (Curve-based)
  • Audio Plug-ins (VST & AU)
  • Audio Drivers (ASIO, WASAPI, DirectSound, CoreAudio, iPhone Audio, ALSA, JACK, and Android)
  • Telecine and Inverse Telecine (Film to TV, TV to Film)
  • Frame Rate Conversions
  • Multi-Processor Support (Performance)
  • Python and Ruby Bindings (All Features Supported)
  • Qt Video Player Included (Ability to display video on any QWidget)
  • Unit Tests (Stability)
  • All FFmpeg Formats and Codecs Supported (Images, Videos, and Audio files)
  • Full Documentation with Examples (Doxygen Generated)


Detailed instructions for building libopenshot and libopenshot-audio for each OS. These instructions are also available in the /docs/ source folder.

Hardware Acceleration

OpenShot now supports experimental hardware acceleration, both for encoding and decoding videos. When enabled, this can either speed up those operations or slow them down, depending on the power and features supported by your graphics card.

Please see doc/ for more information.


Beautiful HTML documentation can be generated using Doxygen.

make doc

(Also available online:


Are you interested in becoming more involved in the development of OpenShot? Build exciting new features, fix bugs, make friends, and become a hero! Please read the step-by-step instructions for getting source code, configuring dependencies, and building OpenShot.

Report a bug

You can report a new libopenshot issue directly on GitHub:



Copyright (c) 2008-2021 OpenShot Studios, LLC.

OpenShot Library (libopenshot) is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

OpenShot Library (libopenshot) is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with OpenShot Library. If not, see

To release a closed-source product which uses libopenshot (i.e. video editing and playback), commercial licenses are also available: contact [email protected] for more information.

  • QtTextReader and QtHtmlReader

    QtTextReader and QtHtmlReader

    I've been looking in to making some improvements to working with text in in libopenshot. One main feature in particular is to have text of different colours in a sentence. You see it quite a lot on news and social media videos where some of the words are highlited. Unfortunately I couldn't see a way to do this with Magick++.

    The best solution I could come up with was to use Qt's HTML features to do this and created QtHtmlReader - it supports all the HTML features here: Along the way we created a QtTextReader as well.

    An added bonus is that both of these are much faster than ImageMagick, nearly 3 times faster in my tests, even the HTML is faster.

    We've tried to follow the existing libopenshot code as best as possible. If you would like to merge these readers please review and suggest any changes/quaility/improvements. @ferdnyc I have removed the std namespace following your current pull request (#296).

    Special thanks to @jediserg who figured out the Qt stuff and wrote most of the code for this.

    opened by jeffski 63
  • Silence deprecated warnings in ffmpeg 3.x

    Silence deprecated warnings in ffmpeg 3.x

    The deprecated calls are and will be present in ffmpeg 3.x and later version use other calls. Therefore, the warning is useless and obscures only important warnings.

    opened by eisneinechse 55
  • Release of libopenshot 0.2.4 (SO 18)

    Release of libopenshot 0.2.4 (SO 18)

    This PR represents the release branch for libopenshot, version 0.2.4 (SO 18), and will be used during the release testing. Feel free to comment, or send PR's for this release branch.

    Related PR's:

    • libopenshot-audio release:
    • openshot-qt release:
    opened by jonoomph 42
  • Python bindings do not seem to work.

    Python bindings do not seem to work.

    if the doc/ is accurate, doing mingw32-make install should copy the binary files to C:\Program Files\openshot\lib, and the header files to C:\Program Files\openshot\include... This is where other projects will look for the libopenshot files when building.. Python 3 bindings are also installed at this point.

    with that said, doing Python

    import openshot

    gave me an error

    Traceback (most recent call last): File "", line 1, in File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\", line 15, in import _openshotTest ImportError: DLL load failed: The specified module could not be found.

    I'm not entirely sure if this is due to the Python bindings or the numerous tweaks I have done to the files to get it this far.

    Help would be deeply appreciated!

    opened by cminghao 42
  • Making OpenShot easier for newcomer developers

    Making OpenShot easier for newcomer developers

    I've been watching your project, and it is very interesting, but appears to be moving slowly and not having too many outside contributors.

    One of the reasons why is that contributing a new feature to your system (including the UI) requires knowledge in 3 domains: C++, Python, and Angular. Those are each huge. Imagine trying to find a writer that understood Spanish, Japanese, and Hindi. There are many millions of people who speak those languages, but not all three!

    In fact, many people who use Python, don't like Javascript. Many people who use Javasript don't know Python. Many people who want to make videos don't know how to program C++.

    Libopenshot is about 10K lines of code. I think it could be converted to Python / Numpy in a couple of weeks. That is a fast library, and there are other GPU and optimized Python libraries you could leverage. Porting to Python, and taking advantage of hardware would make Openshot faster and easier to contribute to. In my free time, I don't want to bother with C++. I'd be willing to help even though I don't know your codebase too much.

    Once you've got a PyQT interface, putting Angular on top makes it more complicated. I'm sure it adds some features, but it raises the barrier to entry.

    Can you consider this, and what Python libraries you could take advantage of if you restructured your code? Given the fact that you use ffmpeg and other tools to do the heavy lifting, it seems like you don't need to have much C/C++ to be very fast. Check out Mercurial as an example of a fast codebase with very little C/C++.

    I took a look at this file, for example:

    It seems like that could be converted to Python easily and be fast enough.

    opened by KeithCu 37
  • libavformat missing on compilation.. but its there

    libavformat missing on compilation.. but its there

    Note: I am on rpi3... its just for educational porpoise , I wont make any openshot project on it (but yes on rpi4!!) Note 2: This its a masterpiece software. thanks to make it open source.

    It could be than its broken somehow or its not the required version??

    I will compile master ffmpeg...

    [email protected]:~/Desktop/openshot_dependencies/libopenshot/build $ sudo apt install libavformat-dev
    Leyendo lista de paquetes... Hecho
    Creando árbol de dependencias       
    Leyendo la información de estado... Hecho
    libavformat-dev ya está en su versión más reciente (7:4.1.3-1+rpt1).
    El paquete indicado a continuación se instaló de forma automática y ya no es necesario.
    Utilice «sudo apt autoremove» para eliminarlo.
    0 actualizados, 0 nuevos se instalarán, 0 para eliminar y 0 no actualizados.
    [email protected]:~/Desktop/openshot_dependencies/libopenshot/build $ cmake ../
              Welcome to the OpenShot Build System!
    CMake will now check libopenshot's build dependencies and inform
    you of any missing files or other issues.
    For more information, please visit <>.
    Generating build files for OpenShot
      Building libopenshot (version 0.2.3)
      SO/API/ABI Version: 17
    CMake Error at /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
    Call Stack (most recent call first):
      /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
      cmake/Modules/FindFFmpeg.cmake:161 (find_package_handle_standard_args)
      src/CMakeLists.txt:83 (FIND_PACKAGE)
    -- Configuring incomplete, errors occurred!
    See also "/home/pi/Desktop/openshot_dependencies/libopenshot/build/CMakeFiles/CMakeOutput.log".
    opened by ghost 32
  • Keyframes and Masks play relative to timeline, not clip

    Keyframes and Masks play relative to timeline, not clip

    I have noticed an issue with how the timing of keyframes are applied and also a similar issue that means it's not possible to use a video as a mask.

    I have found that if you have a clip that starts at position 5 on the timeline, (i.e. it plays from the 5th second on the timeline), if I want to add a keyframe animation to the clip (lets say an alpha change) the first keyframe needs to start at second 5.

    This isn't very intuitive as in my mind the keyframe timing should be relative to the clip not the timeline. So the first keyframe should be at 0 to play from the start of the clip.

    I guess it's not a deal breaker as I can work around it. It would just be nice if keyframes were relative to the clip they are attached to and not the timeline.

    One thing that is not working however is using video (FFMpegReader) in Mask effects. It works fine if the clip the mask is added to starts from 0 on the timeline.

    The problem is the mask video seems to play from the start of the timeline so if the mask plays for 5 seconds but the clip starts at 5 seconds then the mask has already finished playing when the clip starts.

    I think this is maybe related to keyframes playing relative to the timeline, the mask also plays relative to the timeline but there is no way to adjust it, If the mask played relative to the clip rather than the timeline it should work.

    If video masks could be used I think you would be able to create some pretty awesome transitions and effects.

    Just posting this now to see if anyone has had the same experience, I'll add some code examples if it helps.

    opened by jeffski 32
  • Symbol not found: _aligned_alloc on MacOS 10.9.5

    Symbol not found: _aligned_alloc on MacOS 10.9.5

    A user reported this to me on MacOS 10.9.5 running our latest Mac builds. When launching OpenShot, an error during loading, looking for a missing symbol: Symbol not found: _aligned_alloc. It is expecting that symbol in /usr/lib/System.B.dylib.

    We are currently building with GCC 8.4 on MacOS 10.15 (Catalina), and using the MacOS 10.9 SDK while building. Hopefully this can be solved with some compiler flags, or something simple. Our current CMake command used on our Mac builder:

    cmake -DCMAKE_CXX_FLAGS=-I\ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -D"CMAKE_INSTALL_PREFIX:PATH=$CI_PROJECT_DIR/build/install-x64" -DCMAKE_CXX_COMPILER=/usr/local/opt/[email protected]/bin/g++-8 -DCMAKE_C_COMPILER=/usr/local/opt/[email protected]/bin/gcc-8 -DCMAKE_PREFIX_PATH=/usr/local/qt5/5.5/clang_64 -DPYTHON_INCLUDE_DIR=/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -DPYTHON_LIBRARY=/Library/Frameworks/Python.framework/Versions/3.6/lib/libpython3.6.dylib -DPYTHON_MODULE_PATH=python -DPython_FRAMEWORKS=/Library/Frameworks/Python.framework/ -D"CMAKE_BUILD_TYPE:STRING=Release" -D"CMAKE_OSX_SYSROOT=/Applications/" -D"CMAKE_OSX_DEPLOYMENT_TARGET=10.9" -D"CMAKE_INSTALL_RPATH_USE_LINK_PATH=1" -D"ENABLE_RUBY=0" ../


    opened by jonoomph 26
  • Public interface for Keyframe

    Public interface for Keyframe

    The current public interface of Keyframe includes the public member Points. I'm about to remove this member. This will might break a lot of code (basically every place where Python code - e.g. in OpenShot-qt - uses keyframe["Points"] ... which is currently 88 places in OpenShot-qt nothing in OpenShot-qt as far as I can see now).

    There's AddPoint(), RemovePoint(), GetPoint() among others. These should be used instead of direct access to the Points member to give Keyframe a chance to keep it's internal state in order (e.g. sort order of points, interpolated values, ..).

    All in all the public interface of Keyframe is a bit chaotic. It supports access to the points similar like a container (add, remove, find, ..) but of course also access to interpolated values (it's main job, after all).

    The question is: How should the public interface of Keyframe look on the C++ side, and what should it look like on the Python side?

    edit: The question shifts a bit ... it's still important to get a clean public interface. But for openshot-qt the only really important functions are Keyframe::SetJsonValue(), Keyframe::AddPoint, the "get functions" and Keyframe::Json().

    opened by musteresel 26
  • Juce 5 changes

    Juce 5 changes

    Adjustments to build libopenshot against a libopenshot-audio built with the new Juce 5.4.3 changes from my companion PR OpenShot/libopenshot-audio#37.

    • All header files (7) which contained #include "JuceLibraryCode/JuceHeader.h" were changed to simply #include "JuceHeader.h", which works in concert with the new include dir layout for libopenshot-audio.
    • Savaged the cmake/Modules/FindOpenShotAudio.cmake discovery code to remove all of the recursive header-file discovery and LIBOPENSHOT_AUDIO_BASE_DIR noise. Now it simply looks for the file JuceHeader.h and considers that location to be the LIBOPENSHOT_AUDIO_INCLUDE_DIR, which it is. So much simpler it's not even funny.

    (Note: DO NOT MERGE until after the corresponding changes to libopenshot-audio are committed. See OpenShot/libopenshot-audio#37 .)

    opened by ferdnyc 26
  • OpenCV: Adapt to API changes in OpenCV 4.5.2+

    OpenCV: Adapt to API changes in OpenCV 4.5.2+

    Seems that OpenCV 4.5.1 has massively altered the cv::Tracker API, with the one our code uses being moved to cv::legacy::Tracker, and a new implementation taking its place in cv::Tracker.

    Why this trigger was pulled with only a revision bump from 4.5.0 to 4.5.1, I cannot for the life of me understand, but cv::TrackerBoosted and friends are present in 4.5.0, but suddenly gone in 4.5.1. I encountered this when trying to build on Windows 10, now that MSYS2 is packaging OpenCV 4.5.1.

    A function cv::legacy::upgradeTrackingAPI() is provided which can seemingly be used to wrap old code. But, since that function is only present in 4.5.1+, it doesn't help us with simultaneous support of OpenCV versions before and after 4.5.1.

    Supporting OpenCV 4.5.1, specifically, turned out to be impossible as the released code is horribly broken for the "legacy" tracking API. There are headers missing from the install that make it unusable. Fortunately, 4.5.2 is since released that corrects this.

    So, this PR blocks use of OpenCV verson 4.5.1 with a warning about the problem, and adds an OpenCVUtilities.h header which normalizes our code to be compatible with both the previous 4.5.0-and-earlier API, as well as the new-legacy 4.5.2+, in the manner of our other *Utilities.h headers.

    The CMake build will define USE_LEGACY_TRACKER on the build command line if the OpenCV version is greater than 4.5.1, and if that macro is defined:

    • OPENCV_TRACKER_TYPE is defined to be cv::legacy::Tracker
    • OPENCV_TRACKER_NS is defined as cv::legacy

    Otherwise, they are cv::Tracker and cv, respectively.

    The rest of the code uses cv::Ptr<OPENCV_TRACKER_TYPE> as the pointer type for tracker, and OPENCV_TRACKER_NS::TrackerImplementation::create() to instantiate trackers.

    Other included changes

    1. I moved the ClipProcessingJobs class into the openshot namespace, because for some reason it wasn't.
    2. I moved some includes around between .h and .cpp files, to avoid over-including headers, and dropped some unnecessary includes
    3. I dropped the using namespace std; from CVTracker.cpp, adding std:: prefixes where needed.
    opened by ferdnyc 24
  • Bump actions/cache from 3.0.1 to 3.0.4

    Bump actions/cache from 3.0.1 to 3.0.4

    Bumps actions/cache from 3.0.1 to 3.0.4.

    Release notes

    Sourced from actions/cache's releases.


    In this release, we have fixed the tar creation error while trying to create it with path as ~/ home folder on ubuntu-latest.


    Fixed avoiding empty cache save when no files are available for caching. (actions/cache#624)


    This release adds the support for dynamic cache size cap on GHES.


    Sourced from actions/cache's changelog.


    • Added support for caching from GHES 3.5.
    • Fixed download issue for files > 2GB during restore.


    • Added support for dynamic cache size cap on GHES.


    • Fixed avoiding empty cache save when no files are available for caching. (issue)


    • Fixed tar creation error while trying to create tar with path as ~/ home folder on ubuntu-latest. (issue)
    • c3f1317 Merge pull request #813 from actions/users/kotewar/upgrading-cache-to-v2.0.6
    • d0a54b9 Fixed typo
    • 8c5bd0c Updated README file with release info
    • c9c0f73 Merge pull request #812 from actions/users/kotewar/upgrading-cache-to-v2.0.6
    • 2b6caae Merge pull request #495 from ostera/patch-1
    • dd58d13 Added release info and upgraded version
    • acace7f Merge branch 'main' into patch-1
    • 438628a Merge pull request #554 from albertstill/improve-restore-key-docs
    • c296e6a Updated @​actions/cache version in license file
    • 7ed7f22 Updated actions/cache to v2.0.6
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    opened by dependabot[bot] 1
  • Huge amount of memory leaks

    Huge amount of memory leaks

    Hi Openshot Team,

    I want to report about huge memory leaks in libopenshot.

    Also I saw some merged PRs fixing some of them, but leaks still exists.

    Here is the simple code snippet demonstrating and confirming it. I'm running this in Ubuntu 20.04.

    #include <string>
    #include <Clip.h>
    #include <OpenShot.h>
    #include <FFmpegWriter.h>
    #include <Timeline.h>
    void renderSimple()
        /// Creating clip
        openshot::Clip clip("videos/1.mp4");
        /// Creating Timeline
        openshot::Timeline timeline(1920, 1080, openshot::Fraction(30, 1), 48000, 2, openshot::ChannelLayout::LAYOUT_STEREO);
        // Adding above created clip into the timeline
        /// Create writer for output video
        auto writer = new openshot::FFmpegWriter("videos/output.mp4");
        // Setting audio and video options
        writer->SetAudioOptions(true, "aac", 48000, 2, openshot::ChannelLayout::LAYOUT_STEREO, 128000);
        writer->SetVideoOptions(true, "libx264" , openshot::Fraction(30, 1),  1920, 1080, openshot::Fraction(1,1), false, false, 1600000);
        // Prepare writer
        // Write only 200 frames from input clip
        writer->WriteFrame(&timeline, 0, 200);
        // Close writer and reader objects
        delete writer;
    int main(int argc, char* argv[])
        /// Adding this line to keep program running in order to check
        /// final memory usage of program after all resource cleanup
        return 0;

    I placed this code in examples/Example.cpp and built from develop branch. I used arbitrary mp4 video, so you can use anything you want. I'm sure that the problem will be visible with any input video.

    I tried to understand from where coming those leaks, but still there is no success. BTW: You can use valgrind to see reports about leaks. I looked on it, but I'm not familiar with openshot source base (which is large enough) to fix it quickly.

    Note: I also included some fixes from this PR, which fixes some additional leaks, but not all of them.

    Can you please take a look?

    Thanks in advance.

    opened by senoalvrtsyan 1
  • WIP: Add FPS, a Fraction subclass with converting powers

    WIP: Add FPS, a Fraction subclass with converting powers


    To do basically any type of timing conversion in libopenshot, you need to know the FPS you're working with. We pass it into nearly every conversion function, in one way or another, because without it you're dead in the water.

    In fact, FPS is so central to the process of conversions like frame<->time or frame<->sample that it makes sense for the object holding the FPS value to be able to perform those conversions itself!

    Solution (so far)

    So, this (very much work-in-progress) PR is an attempt at empowering our FPS values, by subclassing Fraction into a new class, FPS. The FPS class doesn't carry any more information than Fraction, it just has additional methods useful for common conversions. (In fact, the classes are freely convertible in either direction. Which is why all function signatures that take timing values still pass them as Fractions, not FPSs.)

    Where I have made use of FPS, so far, is in the class member objects stored by things like ReaderBase, WriterBase, FrameMapper, etc. Any members holding fps, video_timebase, or audio_timebase values, which used to be type Fraction, are now type FPS.

    The code doesn't (yet) make any more use of those objects than it did when they were Fractions, but all of the unit tests still pass and the change appears to have had zero effect on functionality, which was the goal for this stage.


    The utility of FPS can be seen in the Python bindings (though the same operations are available to the C++ code directly):

    >>> import openshot
    >>> # If we have an FPS value...
    >>> fps = openshot.FPS(24000, 1001)
    >>> # We can convert frame numbers to (start) times: 
    >>> fps.time(1)
    >>> fps.time(25)
    >>> # We can convert time values to frame numbers
    >>> fps.frame(10.0)
    >>> fps.frame(10.01)
    >>> # We can convert frame# to start sample, for a given samplerate
    >>> fps.sample(1, 44100)
    >>> fps.sample(2, 44100)
    >>> fps.sample(3, 44100)
    >>> fps.sample(2, 48000)
    >>> fps.sample(3, 48000)
    >>> # Want to know the sample count for the first 30 frames of video?
    >>> sr = 44100
    >>> from pprint import pp
    >>> pp([fps.sample(f+1, sr) - fps.sample(f, sr)
    ...     for f in range(1, 31)], compact=True)
    [1839, 1839, 1840, 1839, 1839, 1840, 1839, 1839, 1840, 1839, 1839, 1840, 1839,
     1839, 1840, 1839, 1839, 1840, 1839, 1839, 1840, 1839, 1839, 1840, 1839, 1839,
     1840, 1839, 1839, 1840]

    A case of naming

    You may notice that the new method names on FPS are lowercase. Yeah, sorry. I just couldn't, with the capitalized method names. TitleCase is for classes, not for functions. SomeClass::lowerTitleCase (aka antiSentenceCase) is fine, but not SomeClass::FullTitleCase.

    You may also notice that FPS is fully capitalized, rather than the class name being Fps. Yes, yes it is. I'm not even remotely sorry, on that one.

    Though I'll have to consider whether a hypothetical method to retrieve a Frame's FPS should be called Frame::FPS() or Frame::fps(). (Frame::fPS() is no more on the table than Frame::Fps() is.) I think I'm leaning towards the latter, if for no other reason than to avoid clashes with the class name. (...And now I suddenly appreciate just how critical things like decltype() and typename are to writing template code.)

    ...Even more squirrelly, would the Frame class's method to self-convert into other frame rates be called Frame::toFPS() or Frame::toFps()? That's kind of a hard one!

    FPS also has some other adjustments compared to Fraction. Like, where the Python string representation of a Fraction is num:den (used by the OpenShot Profile Selector dialog when displaying Profile details), for FPS I've changed that to num/den. Though, there are arguments for and against displaying either type of value in either format, so I'm not really married to this change yet.

    Next steps

    There's plenty more to add (aside from, like, actually using this in the code itself), but that's the basic idea.

    • [ ] Additional conversions:: More types of conversions could also be added, if they'd be useful. (I thought about adding time<->sample, but I couldn't really think of anyplace where that would actually be useful for anything.) Some sort of ability to convert between different sample rates in some fashion, OTOH, might actually be handy. It could theoretically centralize the calculations necessary to configure resamplers and size buffers, which are currently scattered, in whole or in part, across ad-hoc implementations found in at least FFmpegReader, AudioResampler, and I believe FFmpegWriter as well.

    • [ ] Storing FPS in Frame?: Another thing I've been thinking about is storing an FPS value inside each Frame object that gets created. Frames basically do have an inherent FPS, since things like their sample count and corresponding time duration (also not currently tracked within Frame itself) are completely dependent on the FPS from which it was created, and Frames moving between FPS values need to be converted (hence FrameMapper). But if Frame carried its FPS internally, then it could produce values like start sample and sample duration / time duration on demand, and determining when conversions are required would be simpler.

    • [ ] Unit tests: FPS needs them for itself, and test coverage of anywhere else it's used should ideally be increased to 100% as well.

    • [ ] Documentation: Filling in the class's missing docstrings, at the very least. (But not the ones inherited from Fraction, because it's a feature of Doxygen that you don't have to repeat documentation in every subclass that inherits a member/method. One we should make better use if.)

    enhancement code bindings 
    opened by ferdnyc 2
  • Make better use of Catch2v3 modularity in unit test code

    Make better use of Catch2v3 modularity in unit test code

    In #828 I did a quick hack to enable support for Catch2 version 3.0+, since our macOS CI was failing after Homebrew upgraded.

    The hack achieves basic parity with Catch2 version 2, but the real promise of Catch2 v3 is to enable faster testrunner builds and more efficient unit testing by only incorporating the parts of it that we actually need. If we can get away with using only catch_test_macros.hpp, the Catch project reports that it's five times cheaper than including all of catch.hpp from v2.

    There are some other nice features that might be worth using, iff they're also available in the older Catch2 v2 versions as well. (It's too soon for our tests to require Catch2 v3+ exclusively. #ThanksUbuntuLTS)

    For example, the Catch2::literals namespace defines a literal for Approx values:

    // Instead of writing this
    CHECK(clip.Duration() == Approx(31.0).margin(0.01));
    // We can just write (allowing Approx to pick a sensible default margin)...
    using namespace Catch2::literals;
    CHECK(clip.Duration() == 31.0_a);

    Now that we're building with C++14 support as a requirement, we can take advantage of user-defined literals where available.

    It's worth investigating what improvements can be made to our unit tests, in terms of both code and build configuration.

    code good first issue tests 
    opened by ferdnyc 0
  • tests/ChromaKey: Test QColor stream operator

    tests/ChromaKey: Test QColor stream operator

    The tests/ChromaKey.cpp file contains an operator<< implementation for QColor that I threw together to facilitate direct comparisons in unit tests. For the test file itself to be fully covered, that operator also needs to be unit-tested.

    opened by ferdnyc 1
  • Hardware Acceleration / Low GPU Usage

    Hardware Acceleration / Low GPU Usage

    Hi Openshot Team,

    I'm using libopenshot with hardware acceleration, especially encoding (h264_nvenc), but I see almost no usage of GPU. Only some mb of GPU memory usage is visible and encoding with libx264 and h264_nvenc renders video on exact same times.

    Can you advice how I can speed up the rendering time ?

    opened by senoalvrtsyan 3
  • v0.2.7(Sep 6, 2021)

    Highlights & Features:

    • Refactor of Crop effect
    • Adding X and Y offset to Crop effect
    • Defaulting crop effect to 0 border lengths
    • Bump version to 0.2.7 (SO 21)

    libopenshot Changelog (Version: 0.2.7, SO: 21)

    • 5987878 2021-09-04 Jonathan Thomas Merge branch 'release-20210904' of into release-20210904 HEAD, origin/release-20210904
    • 4106f1f 2021-09-04 Jonathan Thomas Bumping version to 0.2.7, SO 21
    • 82498b2 2021-09-04 Jonathan Thomas Bumping version to 0.2.7, SO 20
    • 5a8ffe3 2021-09-03 Jonathan Thomas Merge pull request #724 from OpenShot/improved-crop-effect origin/develop
    • 5f91ddc 2021-09-03 Jonathan Thomas Reversing y_offset direction to match previous OpenShot crop behavior
    • f9e5db6 2021-09-03 Jonathan Thomas Adding an X and Y offset to the current crop effect, to better support previous clip crop parameters (for migrating crop options from OpenShot 2.5.1 to OpenShot 2.6). Also refactoring the crop effect, to actually copy the pixels into a new image buffer.
    • d58febf 2021-08-26 JacksonRG Merge pull request #718 from OpenShot/default-crop-border-of-zero
    • fc05893 2021-08-25 JacksonRG Merge pull request #721 from OpenShot/merge-master-0.2.6
    • 569b591 2021-08-25 Jackson Merge master 0.2.6 into develop
    • 3275251 2021-08-25 JacksonRG Merge pull request #720 from OpenShot/release-20210819 origin/master
    • 928c37b 2021-08-23 Jackson set default crop border to 0
    Source code(tar.gz)
    Source code(zip)
OpenShot Studios, LLC
OpenShot Studios, LLC
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

null 5 Mar 7, 2022
A project for the latest Steam PC (US) release of Resident Evil 4 that patches the game to use high-quality MP4 video.

A project for the latest Steam PC (US) release of Resident Evil 4 that patches the game to use high-quality MP4 video.

Megan Grass 5 Mar 3, 2022
Dolby AC-4 Audio & ATSC 3.0/HEVC Video Playback

VideoPlayer Qt+ffmpeg+SDL2+Dolby+AC-4+AC4+HEVC+ATSC3.0+4K+video This is a fork of the video player found here:

Stephen Ferrell 4 May 30, 2022
Shotcut - a free, open source, cross-platform video editor

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

MLT Framework 6.6k Jun 23, 2022
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

Team Kodi 13.9k Jun 24, 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

Arrow Interactive 3 Apr 1, 2022
AAAAnimation - An ASCII Art animation program working with FFmpeg and Qt. Some code is written in assembly.

AAAAnimation About This is a term project of the Assembly Language and System Programming course in NCU. It decodes video with FFmpeg and plays ASCII

null 18 May 25, 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 Team 6.2k Jun 26, 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.

ossrs 18.4k Jun 23, 2022
Free plugin-based video converter

SEZE II Смотреть на русском SEZE is a plugin-based video converter for Windows/Linux. You can write your video filter in C++ (see section "How to make

Ilya Halilov 10 Apr 25, 2022
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.

NVIDIA DesignWorks Samples 108 Jun 18, 2022
Minimalist video maker -- simplify your music score video making process!

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

Chen and Sim 5 Jan 11, 2022
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

struktur AG 1.3k Jun 24, 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

Cisco Systems 4.6k Jun 26, 2022
GStreamer open-source multimedia framework

GStreamer open-source multimedia framework

GStreamer GitHub mirrors 1.3k Jun 23, 2022
Even newer Custom Firmware for Xiaomi Cameras based on Hi3518ev200 Chipset. It includes free RTSP, ONVIF and other improvements based on the work by roleoroleo

Why this Yi-Hack-V5 firmware? The answer is simple: missing updates, RTSP and not based on the latest stock firmware (which features improvements and

null 298 Jun 11, 2022
yangwebrtc is a self-developed rtc architecture supporting Webrtc/Srt/Rtmp, including a variety of video and audio codecs and processing, etc.

YangWebrtc Overview yangwebrtc是一个自主研发的支持Webrtc/Srt/Rtmp的rtc架构,包含多种视音频编解码和处理等。 支持视频会议、高清录播直播、直播互动等多种视音频应用。 可用于远程教育、远程医疗、指挥调度、安防监控、影视录播、协同办公、直播互动等多种行业应用

null 287 Jun 23, 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

Twitter 852 Jun 27, 2022
Video game library manager with support for wide range of 3rd party libraries and game emulation support, providing one unified interface for your games.

An open source video game library manager and launcher with support for 3rd party libraries like Steam, GOG, Origin, and Uplay. Includes game emulation support, providing one unified interface for your games.

Josef Nemec 4.1k Jun 24, 2022