On Sun, Jun 26, 2011 at 12:34 PM, Till Theato <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/25/2011 09:50 PM, Dan Dennedy wrote: >> On Fri, Jun 24, 2011 at 6:00 AM, Till Theato <[email protected]> wrote: >> Hi, >> I have an issues with the new frame dropping method introduced in commit >> 5d971b0c208aa17fd4e159a329cd0304558ec140: >> Clip 2 follows clip 1 on one track. Clip 2 has an in value > 0. During >> playback with real_time=1 there is very little dropping while on clip 1. >> However when it reaches the beginning of clip 2 it has to seek and if >> clip 2 is highly compressed this takes a while. Therefore massive >> frame-droppings set in lasting for quite some time. When playback is >> >>> I reproduced it just fine. Please test my recent commit where I try to >>> address this. > > Thanks for the quick fix! Works fine now. > >> >> started a bit after the beginning of clip 2 this doesn't happen. >> In a project with a lot of short clips only every 15th to 20th frame is >> shown. Maybe it would be possible to optionally set an upper limit for >> the number of dropped frames? >> >>> Sure, it could be possible, but I would rather have it behaving well >>> rather than potentially ask the user to adjust something. Before the >>> changes, it was not behaving well in the sense that audio was not >>> continuous under what I consider even moderate loads. Now it does, >>> except still not some very heavy loads, and I exposed this edge case >>> you found. I do not yet claim all edge cases are resolved, but I hope >>> that it is better overall for the 80% of workloads where you want >>> frame-dropping. Let me know what you think of the results. > > In my quick tests it performed pretty well. Of course the number of > dropped frames was huge when playing back a project with short files > from a Canon DSLR with color grading applied but I guess there is no > proper way to go in this case.
An obvious way to go is to disable frame-dropping, if only temporarily. Maybe for some workflows it is not desirable to have a high threshold for max consecutively dropped frames. Maybe it is desirable to have frame-dropping for light and moderate workloads and give up frame-dropping on sections of heavier load. In that case, maybe an application should be able to set that threshold and lower it from its current value of 1 second. Do you think minimum 1 frame per second is good enough or you want to be able to reduce it to 250ms? Or, is it nice to have a mode where you have frame-dropping when it can still do at least 1 fps but then automatically switch to a non-dropping mode when it can not normally sustain 1 fps and then switch back when it can? > If I find another corner case I will report back. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4HidMACgkQzwEyz7QP6nQvSACgzJWzFol+EFqt/EAWALmOEDJz > QbwAniDDZh7ND+RfwIS8vUMbFgFlI8CE > =i303 > -----END PGP SIGNATURE----- > -- +-DRD-+ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
