On Sat, Jan 21, 2017 at 11:55 AM Dan Dennedy <d...@dennedy.org> wrote:
> 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".
>
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>
> 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
