Comment 19 for bug 403154

Hello TJ

It can and does regularly happen without dragging or manually moving the
cursor. This has mostly been on projects once I have built up a number
of transitions or keyframes etc. This does quite quickly get to the
point of freezing on the second or first clip if the video is long and
complex enough.

Helen

On Wed, 2009-09-02 at 19:40 +0000, TJ wrote:
> On Wed, 2009-09-02 at 19:17 +0000, Jonathan Thomas wrote:
> > Good job digging around in the debugger! Here is what we need to do,
> > for this to get fixed. We need to prepare a simple example for Dan
> > which exposes the bug. What I recommend is to use the smallest H.264
> > clip you have, create the simplest OpenShot project possible which maxes
> > out the CPU, and then take a copy of the "Westley.xml" file from the
> > /OpenShot/ folder.
>
> I don't think we can reproduce the issue just playing the file - it is
> triggered by the user dragging the time-cursor back and forth in the
> time-line before the video preview has had a chance to catch up.
>
> Sometimes it can take 15-20 drags/changes of direction to invoke the
> bug. I've never seen it invoked from a simple first play.
>
> I can't think how we can simulate that user interaction with melt alone.
>
> What I will do is try the same thing in kdenlive. It is based on the
> same MLT/ffmpeg dependencies. If both applications can trigger this it
> would make it easier to be sure the issue is in MLT.
>