Hi Dan,
your update trickled down to the Kdenlive master ppa, so I gave it a try
on my "monster" project. Kdenlive now works like a charm when scrubbing
along the critical parts with 11 tracks full of images which are
composited onto each other.
Thank you very much again for this quick update to MLT!
Best regards,
Harald
Am 21.01.2017 um 21:20 schrieb Dan Dennedy:
I just pushed a commit to increase size of all service caches as
number of tracks increase. Maybe you have a way to test it soon.
On Sat, Jan 21, 2017 at 11:56 AM Dan Dennedy <d...@dennedy.org
<mailto:d...@dennedy.org>> wrote:
On Sat, Jan 21, 2017 at 11:55 AM Dan Dennedy <d...@dennedy.org
<mailto:d...@dennedy.org>> wrote:
On Sat, Jan 21, 2017 at 11:40 AM Harald Albrecht
<harald.albre...@gmx.net <mailto:harald.albre...@gmx.net>> wrote:
Ahhhh ... since you've mentioned MLT_AVFORMAT_CACHE, I've
searched the mltframework GitHub repository for queries to
getenv() and found MLT_PIXBUF_PRODUCER_CACHE. Setting this
to 100 now makes melt play the project fine.
So this triggers two questions:
1. What are "sensible" values for
MLT_PIXBUF_PRODUCER_CACHE? The number of parallel tracks?
Or much more?
# of tracks + 1
2. Is it possible for applications that use MLT to control
such settings through API calls?
Yes, with mlt_service_cache_set_size() with the names
"producer_avformat", "producer_avformat", and "qimage.qimage".
Meant to say "pixbuf.pixbuf" instead of "producer_avformat" twice.
Actually, it is not good to be extending mlt_multitrack.c with
information about services. I think what needs to be done is
when track count increases, MLT framework increases the size
of _all_ service caches. The downside of this is that some
properties and environment variables set on services might be
used to limit caching to reduce memory usage, and those limits
are not known at these points. However, I think you cannot
have it both ways: the more tracks you use requires more memory.
Thank you very much for getting me on the right track this
time!
-- Harald
Am 21.01.2017 um 20:25 schrieb Dan Dennedy:
Regression from what version or time frame? Is it really
a regression or a long-standing problem?
From the sound of it, the automatic increment of avformat
producer cache size might not be working as expected. The
automatic part of this is in mlt_multitrack.c: when
tracks are added the size is increased too track count
plus one. That will cause for each frame at least one
producer to release its avformat and avcodec contexts and
file handle and re-open this within another producer.
Try running it with melt command line with env
var MLT_AVFORMAT_CACHE=20 to see if it makes a
difference. That will set a minimum cache size whereas
the default is 4. Obviously, I have been talking about
avformat producer primarily. If you are using images that
might be another matter.
On Sat, Jan 21, 2017 at 11:15 AM Harald Albrecht
<harald.albre...@gmx.net
<mailto:harald.albre...@gmx.net>> wrote:
Hi,
over time I've seen strange performance breakdowns in
my Kdenlive/MLT
projects, where sometimes playback and rendering of a
multi-track
timeline breaks down to a crawl without a compelling
reason (to me, that
is). When six clips are composed of each other (using
the Qt composite &
transform transition), then rendering breaks down
from around 15fps to a
single frame every three seconds or so. CPU load is
negligible, around
16% on a Core i7, so most cores are idle.
I've finally isolated a minimal regression project,
both as .mlt and
.kdenlive files with a few associated image files,
~400kb in total.
melt --version gives "6.5.0", it's from the Kdenlive
git master ppa
which also has the recent git master MLT to offer.
If someone is willing to look into this issue then
I'm happy to send my
regression project. There is no private data included.
With best regards,
Harald
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the
world's most
engaging tech sites, SlashDot.org!
http://sdm.link/slashdot
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
<mailto:Mlt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mlt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
