Re: [Mlt-devel] [PATCH mlt] Clear audio and video context to NULL
Brought to you by:
ddennedy,
lilo_booter
From: Dan D. <da...@de...> - 2011-10-12 02:47:28
|
On Tue, Oct 11, 2011 at 2:16 PM, Dan Dennedy <da...@de...> wrote: > On Tue, Oct 11, 2011 at 2:05 PM, Mikko Rapeli <mik...@ik...> wrote: >> Previewed clip without proxy and then enabled proxy back on in kdenlive. >> I think context can be NULL after return from pthread_mutex_lock() at any >> time and that would need to be checked everywhere. > > It should definitely not be the case that context can be NULL anywhere > anytime. There is somehow inconsistent state introduced. Once again, > the crash stems from KThumb. Mikko, I think my mailbox is missing the latest posts on this thread! Nonetheless, I did some analysis and here are some findings: - The frames produced by avformat do indeed add a reference to the avformat "guts." So, the idea of an "old" frame does not apply as the reference prevents the producer's guts from being flushed from the cache. - Kdenlive does not call mlt_service_cache_set_size(). Rather, I added it to mlt_multitrack to provide a universal solution. However, that size does not take into account additional usage of avformat producers outside of a multitrack composition. - If VDPAU is enabled (mlt ./configure --avformat-vdpau required), then the producer restricts itself to 5 active instances due to limited GPU resources. It *might* be possible to overrun the cache size if you are using VDPAU playing a timeline that has 4 clips (including music) active at the same point in time on the timeline and 2 KThumb threads are running. Likewise, without VDPAU, and on a 8-core, you could overrun the avformat cache size with multiple clips mixing and thumbnailing. More likely there is some race condition. I will do some more of my own testing with Kdenlive. Have to admit I have not been using it much lately due to various projects and tasks. |