Cannot Render Title Images --> "Invalid" #27
Comments
|
You need to specify which script you are using and exactly how you are making something occur. Again, if you are using the kdenlive-build script, that is no longer supported for execution. |
|
I am using the latest mlt-master git: I installed all the dependencies available on Ubuntu 18.04, and proceeded with ./configure and make && make install I then tested the resulting melt binary with both the AppImage and stable ppa version of Kdenlive and in both instances I was unable to render title clips, as the output file would simply depict a black screen saying "Invalid". What could be causing this? |
How? Did you specify the particular melt executable in kdenlive settings? The problem with that approach is the melt is dynamically linked to the MLT libs, and this does not guarantee that you are using the MLT that you built. If you run I am not sure what the cause of this problem is. You should see a message like "[producer_xml] failed to load producer" in the melt output. As you noted, it is failing to load the kdenlivetitle, but I am not sure why. Maybe there is a broken dependency or incompatible/invalid kdenlivetitle file. Once you get the path of libmlt.so that melt is using above, you can also Why are you not using the MLT that comes with AppImage or that apt installs when using the ppa? Does render work with those MLT builds? |
|
Thank you for your efforts and input! You are right, after compiling and installing, everything is put in /usr/local:
Yet ldd /usr/local/bin/melt which is the melt I compiled, shows links to /usr/lib/ which is the melt that was installed with kdenlive from the stable ppa. So now I only need to have the executable refer to the correct libs, right?
|
|
OK, one way to do that is in a terminal: That environment variable export is effective only in that terminal window & session. |
|
There still seem to be some conflicts between libs. Again, thank you very much for your help and patience, most of all. |
|
OK, I have done some extensive testing now. To confirm that this is exclusively an issue with the melt that I built, I downloaded Shotcut (portable) and used the melt executable in the Kdenlive environment, but also generated a render script which I ran from the terminal, to be sure. This version of melt is able to render title clips, but unlike the melt I built, it only uses 1 CPU core (despite specifying 4 threads in the render dialog/kdenlive settings/ and even the render script) subsequently taking much longer to render. (With the kdenlive-multi-render script available on github, I was able to get it to use two cores, though) Ultimately, I need your assistance in properly compiling melt with all the required modules. I compared the mlt modules in the Shotcut folder and my own, and noticed that the compiled melt was missing the following: libmltlinsys.so Could any of those missing libs be causing the problem, and how would I add them while compiling melt, as no required dev packages are mentioned as a dependency? Is there maybe something I need to enable while using After doing some deep google searching, I found that other people's ./configure outputs list much more modules than mine. I tried both the mlt zip from mltframework and the mlt-master git: What am I missing? |
You will need libmltqt.so because that is where kdenlivetitle lives: Make sure your configure scripts includes "--enable-gpl" or qt will be excluded from the build. I can see from your OP that you did not have GPL enabled:
In your configure output, you should see: |
|
Thanks for the tip! I recompiled using Title Clips work properly now, but only 1 CPU core is being used for rendering, quadrupling render times. With the previous melt all 4 cores were running at 100%, so something about the qt modules must still not be right. Is there anything else I should --enable with regards to qt or any other related modules that pertain to the issue at hand? Thanks again for the effort, guys! |
I doubt it. But I don't know anything about the kdenlivetitler. That is maintained by the KDENLIVE developers. It might be better to ask them. |
|
So --enable-gpl and --enable-gpl3 basically includes a whole bunch of qt modules, right? If I get 100% CPU usage on all 4 cores without those two ./configure flags and only 1 CPU core with them, then something must be broken with qt or any other modules these two flags enable, wouldn't you agree? |
No, it enables a few MLT modules, one of which is qt, which houses the kdenlivetitle service.
No, parallel processing is a complicated subject. The services in the qt module cannot directly affect the parallelism of other modules such as avformat and the frame-threaded rendering in mlt_consumer.c. Some services are simply heavy or contain locks to prevent parallelism around code that is not thread-safe. These can create bottlenecks. As you noticed, if a service fails to load, then it repeatedly displays INVALID, which is going to process much faster than the real thing. There are not many build-time options that control parallelism, mainly just runtime. You said you checked it, but you did not specify. Mainly dependencies such as ffmpeg, vid.stab, qt, etc. have some compile-time options that affect performance such as enabling assemblers, libgomp, etc. Basically, there are many variables, and it depends - including your project. You can't honestly compare apples to lemons (incomplete build). |
|
For this test I used mlt 6.11, successfully compiled by Dan Dennedy's build-melt.sh The test file that I am using is the 1080p version of Sintel. CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04 In order to check melt and isolate the problem I simply rendered the first minute of the Sintel short film with the following command:
It obviously works perfectly. Now when I select this melt in the kdenlive environment, and also ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt folder, yields the following results when rendering the first minute of Sintel. And I have tested every single version of kdenlive available on this earth. Also generating and launching the render script from the terminal yields the same result. I have also tested different kdenlive_render executables/libs with the same result. I should note, that using the kdenlive_multirender script in conjunction with the generated render script by kdenlive, while specifying 4 threads, the CPU uses 2 cores at 100%. Now as I have described before, when I compile melt without enabling gpl, the 1 minute of Sintel renders perfectly again, with full utilization on both the CPU and GPU, but from within Kdenlive this time. I conclude that this problem is somehow caused by Kdenlive and related to qt, but I do not possess the knowhow to further analyze it. Edit: With the latest 18.08 Beta18 and the most recent QT version, 2 cores instead of 1 are now being utilized at 100% with the NVENC profile. So this is 100% a QT issue, but I need further insight from a professional like yourself. |
|
kdenlive_multirender talks about threads, but it is really processes. That piece unncessarily complicates the analysis and discussion. So, leave that out. I see from your melt command line and the kdenlive render script that you are not using real_time < -1. If you use real_time=-<N> (goes after Next, Kdenlive uses Qt-based MLT transition qtblend to composite video tracks. If /home/frank/Documents/scripts/script001.sh.mlt has multiple tracks, then it might be in play and thus Qt's image processing. Perhaps your /home/frank/Qt5.11.1 has more optimizations enable by default than the one with your distribution. I know for sure that Qt can be configured at compile-time to disable various SIMD instruction sets to make a theoretically safer binary to execute (it is supposed to use run-time CPU detection to avoid illegal instructions, but maybe some orgs do not trust that enough). I do not know if Qt has support for stuff like OpenML and OpenCL that can be configured in a build to further optimize, but it's possible. |
|
Alright, I believe that I've figured it out, and shall report back after further testing. Here are my findings: Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC enabled, Kdenlive 18.04 AppImage .)Track Composition - "None" After consulting the documentation, I realized that this should be fixed by disabling any surrounding empty tracks, but so far I have not been able to achieve that. .)Track Composition - "Preview" I conclude that the best of both worlds comes into play with this option enabled. .)Track Composition - "High Quality" I will do more thorough testing and read any documentation available, as I absolutely want to understand what exactly these options do. I think it's a bit crazy to have "High Quality" enabled by default, which so heavily impacts performance, while in my opinion not making enough of an effort to alert the user to the extreme effects it may have on render times. I literally spent 72 hours straight, compiling every single version of melt and kdenlive, documenting and testing every possible compilation parameter variation, performance reviews with every available version of Ubuntu, corresponding kernels and nvidia drivers, and every remotely related kdenlive option or workarounds. Kdenlive Website:
|
|
Hello,
Many thanks for your tests, can I let you forward this discussion to kdenlive@kde.org mailing list?
This is the best way to reach kdenlive dev & "qtblend" author (jb) and let other kdenlive users know.
I share your opinion that the default option should be "composite" transition, at least until qtblend gets optimized!
Regards,
Vincent
Le mercredi 25 juillet 2018, 21:47:40 CEST morphological a écrit :
Alright, I believe that I've figured it out, and shall report back after further testing.
It appears that the root cause of this issue has been Track Compositing, all along.
Here are my findings:
Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC enabled, Kdenlive 18.04 AppImage
.)Track Composition - "None"
[CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%] [Render Time: 15s]
I noticed however, that transitions such as for example Slide or Composite are rendered improperly, with certain interference patterns.
After consulting the documentation, I realized that this should be fixed by disabling any surrounding empty tracks, but so far I have not been able to achieve that.
.)Track Composition - "Preview"
[CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%] [Render Time: 20s]
I conclude that the best of both worlds comes into play with this option enabled.
Both the GPU and CPU are almost fully utilized, while it appears that transitions are rendered correctly.
.)Track Composition - "High Quality"
[CPU Utilization: 10% - 14% - 20% - 100%] [GPU Utilization: 6%] [Render Time: 2m58s]
I will do more thorough testing and read any documentation available, as I absolutely want to understand what exactly these options do.
I think it's a bit crazy to have "High Quality" enabled by default, which so heavily impacts performance, while in my opinion not making enough of an effort to alert the user to the extreme effects it may have on render times.
I literally spent 72 hours straight, compiling every single version of melt and kdenlive, documenting and testing every possible compilation parameter variation, performance reviews with every available version of Ubuntu, corresponding kernels and nvidia drivers, and every remotely related kdenlive option or workarounds.
Kdenlive Website:
High Quality: this uses the new Composite and Transform transition (internally known as qtblend). As this option name suggests, it is giving the best compositing quality, at a slight cost of performance. On a fast machine you might be well able to composite several layers of images (with transparency) onto a video clip and play back the timeline at 25fps.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Hey Vincent, I already submitted my findings to the mailing list before I posted them here. I am getting really deep into this now. Render Times have been reduced to 9-10s. I should note that I have since then disabled the vid.stab module in mlt 6.11 and switched to nvidia-396, not sure if that is related. I will post my final test results tomorrow and subsequently close this issue. Thank you Dan, Vincent and Bmatherly! Without you this issue would have melted my face by now. (get it?) |
Successfully compiled melt and it works fine, except when I try to render kdenlvie title clips, the rendered file just shows a black screen saying "Invalid".
The problem is the "kdenlivetitle" module, which is apparently not enabled by default, but I cannot seem to figure out how to get it working. Any ideas?
The text was updated successfully, but these errors were encountered: