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: https://doc.qt.io/qt-5/richtext-html-subset.html. 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.

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.

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: https://github.com/OpenShot/libopenshot-audio/pull/80
• openshot-qt release: https://github.com/OpenShot/openshot-qt/pull/3161

if the doc/INSTALL-WINDOWS.md 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\openshot.py", 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!

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: https://github.com/OpenShot/libopenshot/blob/master/src/TextReader.cpp

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

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.
  rpi.gpio-common
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 <http://www.openshot.org/>.
-----------------------------------------------------------------

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):
  Could NOT find FFmpeg (missing: AVFORMAT_LIBRARIES AVFORMAT_INCLUDE_DIRS)
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".

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.

A user reported this to me on MacOS 10.9.5 running our latest Mac builds. When launching OpenShot, an error during loading PyQt5.QtCore.so, 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/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk" -D"CMAKE_OSX_DEPLOYMENT_TARGET=10.9" -D"CMAKE_INSTALL_RPATH_USE_LINK_PATH=1" -D"ENABLE_RUBY=0" ../

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().

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 .)

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.

Bumps actions/cache from 3.0.1 to 3.2.2.

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.

The issue occurs when using the NVENC options when exporting the video (in openshot-qt). Everything reads and writes fine until frame 33 where FFmpeg unexpectedly returns -22 (Invalid argument) The export works fine on every other option (with CPU or VAAPI) This probably has to do with av_packet_rescale_ts on line 2270 of FFmpegWriter.cpp, it might be wrong (although I can't easily use a C++ debugger on a Python script that is openshot-qt)

OS: Gentoo Linux x86_64 RAM: 16GB CPU: Intel i7-8750H (12) @ 4.100GHz GPU: Intel CoffeeLake-H GT2 [UHD Graphics 630] GPU: NVIDIA GeForce GTX 1050 Ti Mobile libopenshot: 0.3.0 (built from upstream using a custom package manager overlay) nVidia drivers: 525.60.13 FFmpeg: 4.4.3

Here's a log file for reference: libopenshot.log This issue is probably equivalent to the one on https://github.com/OpenShot/openshot-qt/issues/4086

Under

Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.1 LTS
Release:	22.04
Codename:	jammy

A built-from-source v0.3.0 libopenshot, and subsequent src/launch.py yields:

Program received signal SIGSEGV, Segmentation fault.
#0  google::protobuf::io::CodedInputStream::ReadTagWithCutoffNoLastTag(unsigne
    at ./google/protobuf/io/coded_stream.h:1027
#1  google::protobuf::FileDescriptorProto::MergePartialFromCodedStream(google:4b0ca0)
    at google/protobuf/descriptor.pb.cc:1902
#2  0x00007fffeb33ade9 in bool google::protobuf::internal::MergeFromImpl<false) 
#3  0x00007fffeb3aa666 in google::protobuf::EncodedDescriptorDatabase::Add(voi
#4  0x00007fffeb378574 in google::protobuf::DescriptorPool::InternalAddGenerat
#5  0x00007fffeb3ed417 in google::protobuf::internal::AddDescriptors(google::pr
    at /lib/x86_64-linux-gnu/libprotobuf.so.23
#19 0x00007ffff7cb6748 in dlopen_implementation
#24 0x000055555569b3b0 in _PyEval_EvalFrameDefault ()

To get around this, I turned off ENABLE_OPENCV in CMakeLists.txt, and all is good!

Hi, libopenshot looks amazing. I can't figure out the licensing though.

libopenshot says it's LGPL - https://www.openshot.org/libopenshot/ libopenshot-audio says it's GPL - https://github.com/OpenShot/libopenshot-audio and based on JUCE which has a VERY proprietary license: https://github.com/juce-framework/JUCE/blob/master/LICENSE.md

But then this page says libopenshot uses libopenshot-audio as a library: https://github.com/OpenShot/libopenshot/wiki/Linux-Build-Instructions

Not saying your wrong, I'm just confused and need to understand before I use it.

Is libopenshot-audio optional? Is JUCE for audio plugins? Why not use the ffmpeg codecs? Why not have a LICENSE.md in the repo?

Thank you!

Adding gamma adjustment is my priority. I can easily substitute the code for brightness in the existing plugin. What would be the preferred form of adding the feature? An additional parameter in the existing brightness/contrast 'plugin', or a seperate plugin?