Comment 16 for bug 403154

Ahhh, that makes more sense. As the user drags the play-head, I issue a
"seek" / "pause" command over and over again to the correct frame. I
suppose it's possible that MLT is busy rendering the current audio sample /
or video sample while I'm issuing the seek (or pause) command. Or something
similar to that.

I agree, it would be difficult to reproduce this with melt. It's also
possible that there is a better way to handle seeking in MLT.

Let me know if Kdenlive can reproduce this. Once I know that, I will send
an email to Dan with all the debug output, and my best description of what
is happening.

Thanks,
-Jonathan

On Wed, Sep 2, 2009 at 2:40 PM, TJ <email address hidden> 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.
>
> --
> 100% CPU core usage when previewing time-line
> https://bugs.launchpad.net/bugs/403154
> You received this bug notification because you are the registrant for
> OpenShot Video Editor.
>
> Status in OpenShot Video Editor: In Progress
>
> Bug description:
> Using complex keyframes can cause the viewing port to freeze so it will not
> play anymore.
>
> I have tested this with Jonathan's original Vimeo demo clip with the dog
> and the leaves.
>
> I have attached project .osp file for examination.
>
> I put the clip on the timeline, and set the clip properties so Video had
> fill enabled.
>
> I then set layout->end->x to 100% so it wiped across the screen
>
> I then duplicated this clip and placed the copy below it, and synchronised.
>
> On the duplicate I set layout->start->x to -100% and layout->end->x to 0%
> so it wiped across following the upper clip.
>
> At this point in the editing, the timeline would usually play without the
> viewing window freezing, but sometimes the viewing window would freeze and I
> would have to close OpenShot and re-start it.
>
> The next thing I did was to switch the sound to "off" on the lower
> duplicate clip.
>
> With these settings the timeline could not run fully without the viewing
> port freezing.
>
> Also it had another dramatic effect!
>
> If I re-loaded this saved project at this state, it would sometimes
> completely hang OpenShot as it tried to load!
>
> Sometimes it would load but without the clips being on the timeline, so
> only the parent clip showing in the Project Files tab.
>
> Sometimes it would load fully and I could play part of the timeline before
> the viewer froze.
>
> Helen McCall
>