Last MLT build on PPA was 2 days ago, so if you upgraded recently you shouldn't have the mid-september issue.
FFmpeg PPA provides renamed libav*.so, and only ffmpeg utilities linked to it, not MLT, so it is not used for Kdenlive editing/rendering (only ffmpeg can be pointed at for transcodings/proxies)

I confirm. Upgraded to 0.9.10 from Sunab PPA. MLT environment still has no encoder thread option. Rendering is still not using cpu potential. My performance is still 1/2 that of 0.9.6. Regressing and locking the version again.

So you rolled back by removing the sunab PPA, purging, and installing from the ubuntu PPA?

EDIT: Just downgraded back myself. Renders take 1/2 to 1/4 the time and produce a smaller file size using the same settings on 0.9.6 vs 0.9.10.

jkolodziej wrote:So you rolled back by removing the sunab PPA, purging, and installing from the ubuntu PPA?

No. I rolled back by disabling the Sunab PPA, purging, reloading, then reinstall from the main Ubuntu repository.

Also worthy of note is the fact that even with 0.9.6 there is still a problem whereby the rendering and file creation are not happening together. It seems to render to memory or some other cache location, then when the progress bar is nearly done it slowly writes to the file. Very strange.

Odd, when I rolled back my progress bar/file creation issue went away. One thing I did that you didn't do was after I disabled Sunab PPA, and purged KDENLive, I did an apt-get autoremove. That removed MLT 6 as well. Then I reinstalled from the Ubuntu PPA and now everything seems peachy keen.

jkolodziej wrote:Odd, when I rolled back my progress bar/file creation issue went away. One thing I did that you didn't do was after I disabled Sunab PPA, and purged KDENLive, I did an apt-get autoremove. That removed MLT 6 as well. Then I reinstalled from the Ubuntu PPA and now everything seems peachy keen.

could you please be exact with the steps you took to get kdenlive back to it's optimal rendering performance? i'm using Xubuntu 14.04.1 with kdenlive-release sunab ppa. i get ffmpeg from the jon-severenson ppa if that's of any consequence. if you could please list out each and every package and their version it would be much appreciated. what a mess.

currently I have the following as reported by aptitude
melt=0.9.3+git20141005.22abed67-0ubuntu0~sunab~trusty1
libmlt6=0.9.3+git20141005.22abed67-0ubuntu0~sunab~trusty1
kdenlive=0.9.10-0ubuntu0~sunab~trusty1
ffmpeg=7:1.2.6-1~trusty1
libavtools=7:1.2.6-1~trusty1
frei0r-plugins=1.4.0+git20140826.72e51041-0ubuntu0~sunab~trusty1

i couldn't find avconv in aptitude so i used avconv --version
avconv --version
ffmpeg version 1.2.6-7:1.2.6-1~trusty1 Copyright (c) 2000-2014 the FFmpeg developers
built on Apr 26 2014 18:52:58 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --arch=amd64 --disable-stripping --enable-avresample --enable-pthreads --enable-runtime-cpudetect --extra-version='7:1.2.6-1~trusty1' --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --enable-bzlib --enable-libdc1394 --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-libcdio --enable-x11grab --enable-libx264 --shlibdir=/usr/lib/x86_64-linux-gnu --enable-shared --disable-static
libavutil 52. 18.100 / 52. 18.100
libavcodec 54. 92.100 / 54. 92.100
libavformat 54. 63.104 / 54. 63.104
libavdevice 53. 5.103 / 53. 5.103
libavfilter 3. 42.103 / 3. 42.103
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100

I guess you have to lock the mlt packages from ubuntu to prevent PPA from replacing them, as they seem to buffer output in memory until end.
MLT multithread rendering is enabled again in kdenlive-svn repo, no need to switch back to kdenlive 0.9.8.

Ubu the Tech Guru wrote:

jkolodziej wrote:Odd, when I rolled back my progress bar/file creation issue went away. One thing I did that you didn't do was after I disabled Sunab PPA, and purged KDENLive, I did an apt-get autoremove. That removed MLT 6 as well. Then I reinstalled from the Ubuntu PPA and now everything seems peachy keen.

could you please be exact with the steps you took to get kdenlive back to it's optimal rendering performance? i'm using Xubuntu 14.04.1 with kdenlive-release sunab ppa. i get ffmpeg from the jon-severenson ppa if that's of any consequence. if you could please list out each and every package and their version it would be much appreciated. what a mess.

currently I have the following as reported by aptitude
melt=0.9.3+git20141005.22abed67-0ubuntu0~sunab~trusty1
libmlt6=0.9.3+git20141005.22abed67-0ubuntu0~sunab~trusty1
kdenlive=0.9.10-0ubuntu0~sunab~trusty1
ffmpeg=7:1.2.6-1~trusty1
libavtools=7:1.2.6-1~trusty1
frei0r-plugins=1.4.0+git20140826.72e51041-0ubuntu0~sunab~trusty1

i couldn't find avconv in aptitude so i used avconv --version
avconv --version
ffmpeg version 1.2.6-7:1.2.6-1~trusty1 Copyright (c) 2000-2014 the FFmpeg developers
built on Apr 26 2014 18:52:58 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --arch=amd64 --disable-stripping --enable-avresample --enable-pthreads --enable-runtime-cpudetect --extra-version='7:1.2.6-1~trusty1' --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --enable-bzlib --enable-libdc1394 --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-libcdio --enable-x11grab --enable-libx264 --shlibdir=/usr/lib/x86_64-linux-gnu --enable-shared --disable-static
libavutil 52. 18.100 / 52. 18.100
libavcodec 54. 92.100 / 54. 92.100
libavformat 54. 63.104 / 54. 63.104
libavdevice 53. 5.103 / 53. 5.103
libavfilter 3. 42.103 / 3. 42.103
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100

Like I said, I disabled Sunab's PPA then:

sudo apt-get purge kdenlive
sudo apt-get autoremove
sudo apt-get update
sudo apt-get install kdenlive

Purge removes kdenlive. Autoremove gets rid of other related packages like mlt and avconv. Update updates the sources minus Sunab PPA. install reinstalls kdenlive. That's all I did.

ddennedy wrote:

zerofossilfuel wrote:Wow. I see what you mean. I wonder of that's been fixed?

According to a recent bug report on the MLT mailing list, no. Please help identify the primary effect that is causing it. "Any kind of alpha operations" is incorrect unless you refer specifically to the "Alpha operations" effect within Kdenlive.

I have an update about the alpha compositing rendering glitches with multi-threaded MLT processing. We recently found two more frei0r filters people often use with chroma keying that were causing problems and added them to our multi-threading blacklist. You can fix this without a new build of MLT (but the fix might get overwritten by a package upgrade). If you locate the MLT install that your Kdenlive is using, for example if /usr, then you can edit /usr/share/mlt/frei0r/not_thread_safe.txt. There should be an existing file there with some filters listed. Add these 2 to the list, each on their own line:
keyspillm0pup
alpha0ps

While the routines of those filters will no longer be operating in parallel there can still be other routines such as scaling, deinterlacing, compositing, and various other effects that will run in parallel. These locks and barriers that intentionally inhibit multi-threaded access are examples of how the parallel processing is not always able to maximize usage of system resources. It creates bottlenecks in the processing pipleline. In my testing on a Core i7 with 8 logical cores (the best I have), the speed gains diminish quickly beyond 3 or 4 depending upon the project details. You might as well limit your MLT thread usage and let the encoding codec use the rest. If you are on a dual core, I do not recommend any MLT parallel processing. On a quad core, I recommend only 2 threads and on a 6 core, 3.

One disadvantage to rolling back to 0.9.6 is that I now have to use proxy clips once again for HD content. On 0.9.10 this wasn't necessary for whatever under-the-hood reasons. Might experiment later with doing another upgrade from here to see if I accidentally introduced an incompatibility before that caused my problems.

EDIT: After doing nothing more than re-enabling the Sunab PPA and updating through the muon application updater, I am once again confronted with the situation where rendering the file appears to take 2 passes (file builds to less than 1mb until the end, when it starts to fill up to actual size in the last "minute" of rendering). There is something broken in the current packages that causes this condition.

ddennedy wrote:

ddennedy wrote:

zerofossilfuel wrote:Wow. I see what you mean. I wonder of that's been fixed?

According to a recent bug report on the MLT mailing list, no. Please help identify the primary effect that is causing it. "Any kind of alpha operations" is incorrect unless you refer specifically to the "Alpha operations" effect within Kdenlive.

I have an update about the alpha compositing rendering glitches with multi-threaded MLT processing. We recently found two more frei0r filters people often use with chroma keying that were causing problems and added them to our multi-threading blacklist. You can fix this without a new build of MLT (but the fix might get overwritten by a package upgrade). If you locate the MLT install that your Kdenlive is using, for example if /usr, then you can edit /usr/share/mlt/frei0r/not_thread_safe.txt. There should be an existing file there with some filters listed. Add these 2 to the list, each on their own line:
keyspillm0pup
alpha0ps

While the routines of those filters will no longer be operating in parallel there can still be other routines such as scaling, deinterlacing, compositing, and various other effects that will run in parallel. These locks and barriers that intentionally inhibit multi-threaded access are examples of how the parallel processing is not always able to maximize usage of system resources. It creates bottlenecks in the processing pipleline. In my testing on a Core i7 with 8 logical cores (the best I have), the speed gains diminish quickly beyond 3 or 4 depending upon the project details. You might as well limit your MLT thread usage and let the encoding codec use the rest. If you are on a dual core, I do not recommend any MLT parallel processing. On a quad core, I recommend only 2 threads and on a 6 core, 3.

where is MLT parallel processing defined? i'm only aware of the threads setting in the render dialog box. Thanks for looking into this, it's really appreciated!

Right here.

Note that the setting was removed in 0.9.10 release, restored in git

is it critical to perform the modifications listed above by ddennedy in order to not have issues with multi-core melt processing? i'm trying to understand what it was removed for 0.9.10 release but now brought back in GIT?

Ubu the Tech Guru wrote:is it critical to perform the modifications listed above by ddennedy in order to not have issues with multi-core melt processing? i'm trying to understand what it was removed for 0.9.10 release but now brought back in GIT?

I would guess the threadsafe blacklisting would only be necessary if you use those two frie0r filters.

As to what was removed and then returned - it is is the "processing threads" option in the configure kdenlive > environment>Melt tab