Comment 20 for bug 403154

Hello Jonathan,

I have had it happen once when I tested TJ's package of the new
kdenlive. It only happened once I had built up a few clips on the
timeline.

I might be able to find a small project which does this bug on first
play. I am too tired tonight to look for this one, so I will have to do
it at the weekend.

Helen

On Wed, 2009-09-02 at 20:20 +0000, Jonathan Thomas wrote:
> 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
> >
>
> --
> 100% CPU core usage when previewing time-line
> https://bugs.launchpad.net/bugs/403154
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> 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
>