Release of libopenshot 0.2.4 (SO 18) #407
Conversation
- Use same `html_code` and `css_code` - Sync up offsets and gravity (BOTTOM_RIGHT) - Create 1280x720 frames - Generate 100 frames of output video
Makes nearly all `file_path` arguments optional, unless the exception deals with file operations specifically (e.g. InvalidFile still requires file_path)
Add a Python example in src/examples/Example.py
Extend openshot::Fraction in the Python wrapper, to permit: ```py f = openshot.Fraction(16, 9) float(f) # returns 1.777777777 int(f) # returns 2 print(f) # outputs "16:9" dict(f.GetMap()) # in Python dict form
Codacy pointed out that there's absolutely no reason to be importing the sys module in this code.
Example.py: Remove useless `import sys`
- Don't precede with two blank lines - "Decodiing" was misspelled - Less cryptic text
Instead of the hardcoded `/home/jonathan/...` input path, load the input file from TEST_MEDIA_PATH, defined as in `tests/CMakeLists.txt`
We don't _just_ use the ZeroMQ library, we also use the cppzmq bindings. Previously we weren't detecting for those at all. This adds a check for its configs, and adds its target to the openshot target linking (even though it's a header-only library).
Our copy of the module is outdated, and fails detecting Python 3.8. (Besides, we shouldn't be mirroring standard CMake modules.)
|
And AppImages built with 22793e2 have libresvg.so linked properly! \o/ Now to actually test the color-inversion fix... |
|
@jonoomph Whoop! Well, we're closer. Now I get a C++ traceback/crash in the AppImage, trying to drag an SVG title file from Project Files to the Timeline. But I'm not sure that one's my fault, because this is the traceback: And I happened to notice these messages in the builder logs of the last few linux builds (note the Path/versioning issue on the linux builder, perhaps? |
|
Indeed, from exploring the AppImage I can say that it does not contain $ cd /tmp/.mount_avJWHX
$ ls usr/bin/*ssl*
usr/bin/_ssl.cpython-34m-x86_64-linux-gnu.so
$ ldd usr/bin/*ssl*
linux-vdso.so.1 (0x00007ffc602dd000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f00f2980000)
libc.so.6 => /lib64/libc.so.6 (0x00007f00f27b7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f00f2c18000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found(My local system offers only |
Hmm, those are Maybe I should add a command-line flag that will make those |
|
@ferdnyc, here are those files on the Linux build server: |
|
AppImages now launch, and resvg is updated, but I'm still seeing the inverted gradient colors. Hmmm... Can anyone else confirm? |
|
✔️ Mac: resvg works nicely, supports alpha gradients, and all titles work (including the default font)
|
|
@ferdnyc Perhaps the Linux version of Qt5 is too old, and has some other issue. We are currently running: |
|
@jonoomph Agreed, if it wasn't the image format, then I'm inclined to just blame Qt 5.2 in general. |
|
@ferdnyc Do you convert produced image from ARGB_Premultipled to RGBA8888 manually? Maybe automatic conversion is broken in this version of Qt? I still insist that this issue is not related to |
I absolutely agree with you! Especially since it turns out that I'm an idiot. Twice over. When I made the change to our resvg code, I fixed the image-loading code, but missed that there was a copy-paste version of the exact same conversion code in So, it's fully expected that nothing would've changed in the AppImage builds made after my previous "fix" (which fixed only the wrong code, effectively). The commits I just pushed make the same change to the Of course, the build host is down for a failed update of Qt, since we were thinking that was the problem. So it'll be hard to confirm that immediately. |
|
What we do now, though, for the record, is this: libopenshot/src/QtImageReader.cpp Lines 219 to 254 in 1750629 Ugh, that's almost impossible to read with GitHub's page formatting. |
|
Basically, we set up a buffer that's (now) explicitly in (Edit: Corrected buffer format) |
|
So, I think we should hold off on this release for just around a week longer, based on what I've discovered today. Let me preface this by saying that I've been sitting on it for hours, trying to figure out where I made some mistake or misinterpreted some data, because I didn't even believe it myself. I figured I must've made an error somewhere. But the more I test, the more unbelievable the results get, and I've finally decided to accept that I might just be right about this. Qt are not kidding around, about the performance differences between various QImage formats. The
Then I wrote some benchmark scripts, to compare the code on this branch to the modified I created a complex project in OpenShot, where "complex" means that from the very first frame, there are always FIVE tracks with video running on them, all with their Alpha properties set for semi-transparency, and with keyframed transforms constantly going on. There are videos rotating, other videos scaling and sliding around behind them, a couple of the middle videos shrink down and walk around the screen as they fade in and out of visibility... it's a chaotic, incomprehensible mess, in short. I saved that project, removed the history from the file, and then ran Export time trials in the GUI. Using the same OpenShot code (the release branch over there), I
Like I said, I didn't believe it either. So I modified my benchmark scripts to use the new project, and set them up to test the encode path specifically: create a Timeline, set up a Writer, and then repeatedly do Then I ran best-of-three timing trials between the two branches, now performing three tests:
(Each result is the best of three runs.)
I keep running it, and the results are the same: Whether in benchmarks or interactively, for complex compositing operations QImage/QPainter using Now, there's an obvious issue with this, currently: The colors are all out of whack. To complete the format-change, I have to go through the code, find all the places where we bit-hammer the image bytes directly, and reorder them from RGBA to ARGB. (Or, more likely, rewrite the code to use Qt's It'll take a bit of work, and a few days to get it right probably. But... I mean... it sounds worth it, no!? |
Actually, the funny thing is, that's only true of the preview widget. The exported colors are perfect, the way we deliver the image data to FFmpeg must be able to handle the format change. I used this technique to diff the results of both of the OpenShot exports above, and the image was solid gray (no differences at all) except for one video I included that's cropped to a non-standard size of But other than that, the output videos were 100% identical. One of them just got written 5½ seconds faster than the other. |
|
@ferdnyc This sounds very promising indeed!!! Yes, let's hold off the release for a few more days and see how this turns out. 🤞 Please let me know when the branch is ready for some testing, and I'll give is a try on all 3 OSes. |
Last time it was mentioned here: OpenShot/openshot-qt#3152 |
|
Depending on how Preview looks for you, you may try to change the |
Unfortunately we can't use that, as it's only present in Qt 5.9 and later. But Regardless, the code wasn't coming together as quickly as I'd hoped, as our direct bit-access makes a format change somewhat complicated. So @jonoomph and I decided to postpone it for after the release. Once the release is done I'll get my in-progress changes into a more coherent state and create a branch off of |
|
I did want to ask @jonoomph if he's seen #416, though, and might want to incorporate it into the 0.2.4 release — as I said in the PR, it made a huge difference in preview playback on my system, and we've had more reports come in (OpenShot/openshot-qt#965) just today about poor preview performance. |
|
Looking at #416 now. I'm a little concerned about the memory requirements of this change. I'm gonna test it real quick though. |
… not see any crazy memory demands from this.
|
Okay, in my tests this worked great. About to merge for final release |
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: