On Sat, Jan 21, 2017 at 11:40 AM Harald Albrecht <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". 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>
> 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
> 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
