100% CPU core usage when previewing time-line

[Helen McCall]

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

[Jonathan Thomas (jonoomph)]

Helen, are your media files located on your primary harddrive? or an external harddrive? Also, please check your "System Monitor", and see what the CPU is doing while OpenShot is hanging. And, as a side note, see how many "Python" processes are running on your computer. There should only be a few. Thanks!

[Helen McCall (wildnfree)]

Wow! This test with the system monitor has woken me up from my tired
state.

The video files are all on a "projects" partition on one of my internal
harddrives (SATA2). I ran the subsequent tests with only OpenShot,
System Monitor, and Evolution running.

I monitored first: The clip freezing in the viewport, but leaving
Openshot still working in all other respects.

Prior to this viewport freeze, all processors had their loads reasonably
evenly spread with activity in the middle ranges for all of them.

When the viewport froze, one processor went up to 100% and just stayed
there like it was in a never ending loop. The other two processors went
down to a low level of load around 10% or lower. Any activity like
moving the timeline curser or opening a dialogue window caused the two
low level processors to increase their activity a little.

The only thing I found which changed this situation was to open a
file-selection dialogue for importing a clip. This caused the 100%
processor to swap with one of the other processors, so that a different
processor was stuck at 100%, and the original high load processor was
now one of the pair of low load processors!

Second test: Openshot freezing completely on opening the project I sent
you. This did the same thing and caused one processor (#2) to go to
100%, and the other two (#1 & #3) to go to very low load.

I couldn't use the Openshot file-selection dialogue, so I opened gedit.
no activity on that or on the terminal window affected the state of this
#2 100% processor, except opening the file dialogue on gedit caused #2
to go low level, and #1 to switch to 100%! I tried this a few times and
it always caused a different processor to go to 100%. After leaving one
processor running for a few minutes at 100%, the opening of a
file-selection dialogue didn't switch the processors any more. Leaving
that processor permanently at 100%

On killing OpenShot with a "Force Quit", the 100% processor immediately
dropped down to low level and joined the other two so I had then all
three processors in a balanced load at low level.

Therefore I would surmise that freezing of the viewport or the whole of
OpenShot both are caused by a never ending loop as some process is
waiting for a result from a sub process which has probably died, and the
waiting is not being timed out.

Women's intuition suggests to me either: that one of the MLT functions
has a bug where it fails to return an error code when failing. Or else
some function in the Python code is failing to test for the error return
from a function, and is just looping and calling until it gets what it
considers to be a valid return value (which never comes)

 A clue to where this might be is that any call to the Gnome
file-selection dialogue, causes that looping process to be re-spawned on
a different processor. (Wow! This takes me back nearly 20 years to when
I was learning to program Transputer arrays in the Occam2 language!)

At soem point in all of this, some process related to the file selection
is timing out but leaving the looping process as an orphan and so then
it never switches until the application is killed and all related
processes are sent the kill signal. ...

[Jonathan Thomas (jonoomph)]

Helen,
The processors switching between 100% from CPU 1 to CPU 2, etc... are
probably happening based on how the Linux kernel handles multiple
processors. The CPU selection happens on a much lower level than what I'm
doing in Python. However, there is obviously a problem with OpenShot maxing
out at 100% CPU.

Can you recreate this behavior using the new version you installed with .DEB
files?

On Thu, Jul 23, 2009 at 5:57 PM, Helen McCall <email address hidden>wrote:

> Wow! This test with the system monitor has woken me up from my tired
> state.
>
> The video files are all on a "projects" partition on one of my internal
> harddrives (SATA2). I ran the subsequent tests with only OpenShot,
> System Monitor, and Evolution running.
>
> I monitored first: The clip freezing in the viewport, but leaving
> Openshot still working in all other respects.
>
> Prior to this viewport freeze, all processors had their loads reasonably
> evenly spread with activity in the middle ranges for all of them.
>
> When the viewport froze, one processor went up to 100% and just stayed
> there like it was in a never ending loop. The other two processors went
> down to a low level of load around 10% or lower. Any activity like
> moving the timeline curser or opening a dialogue window caused the two
> low level processors to increase their activity a little.
>
> The only thing I found which changed this situation was to open a
> file-selection dialogue for importing a clip. This caused the 100%
> processor to swap with one of the other processors, so that a different
> processor was stuck at 100%, and the original high load processor was
> now one of the pair of low load processors!
>
> Second test: Openshot freezing completely on opening the project I sent
> you. This did the same thing and caused one processor (#2) to go to
> 100%, and the other two (#1 & #3) to go to very low load.
>
> I couldn't use the Openshot file-selection dialogue, so I opened gedit.
> no activity on that or on the terminal window affected the state of this
> #2 100% processor, except opening the file dialogue on gedit caused #2
> to go low level, and #1 to switch to 100%! I tried this a few times and
> it always caused a different processor to go to 100%. After leaving one
> processor running for a few minutes at 100%, the opening of a
> file-selection dialogue didn't switch the processors any more. Leaving
> that processor permanently at 100%
>
> On killing OpenShot with a "Force Quit", the 100% processor immediately
> dropped down to low level and joined the other two so I had then all
> three processors in a balanced load at low level.
>
> Therefore I would surmise that freezing of the viewport or the whole of
> OpenShot both are caused by a never ending loop as some process is
> waiting for a result from a sub process which has probably died, and the
> waiting is not being timed out.
>
> Women's intuition suggests to me either: that one of the MLT functions
> has a bug where it fails to return an error code when failing. Or else
> some function in the Python code is failing to test for the error return
> from a function, and is just looping and calling until it gets what it
> consid...

[Helen McCall (wildnfree)]

Hello Jonathan,

Yes this still happens with 0.9.8 all installed from .deb packages. The
only bit that I've had happening is the freezing of the viewport whilst
playing. Still the same effects on System Monitor.

One difference (caused I think by the different way of launching
Openshot with a sh script) is that the process doesn't die when I kill
OpenShot. I have to kill the terminal window as well before the 100%
process dies.

This is a menace because it is making it difficult for me to edit the
circus film projects I am working on.

I can reduce the chances of a freeze if I first drag the cursor all the
way along the timeline before trying to play it. I have a niggling
feeling that this has something to do with one of the length attributes.
I was having so much trouble at first with the released form of 0.9.7
and 0.9.8 that I didn't manage to log all the bugs that occurred, but
several of them were giving error messages on the console relating to
length attributes.

The files I am working on for the circus project are all mp4 files
rendered by OpenShot from AVCHD clips from my camera. This technique was
working fine until version 0.9.7 when the freezes became too prevalent.
I was using 0.9.4 before that.

Helen

On Mon, 2009-07-27 at 13:55 -0500, Jonathan Thomas wrote:
> Helen,
> The processors switching between 100% from CPU 1 to CPU 2, etc... are
> probably happening based on how the Linux kernel handles multiple
> processors. The CPU selection happens on a much lower level than what
> I'm doing in Python. However, there is obviously a problem with
> OpenShot maxing out at 100% CPU.
>
> Can you recreate this behavior using the new version you installed
> with .DEB files?
>
> On Thu, Jul 23, 2009 at 5:57 PM, Helen McCall
> <email address hidden> wrote:
> Wow! This test with the system monitor has woken me up from my
> tired
> state.
>
> The video files are all on a "projects" partition on one of my
> internal
> harddrives (SATA2). I ran the subsequent tests with only
> OpenShot,
> System Monitor, and Evolution running.
>
> I monitored first: The clip freezing in the viewport, but
> leaving
> Openshot still working in all other respects.
>
> Prior to this viewport freeze, all processors had their loads
> reasonably
> evenly spread with activity in the middle ranges for all of
> them.
>
> When the viewport froze, one processor went up to 100% and
> just stayed
> there like it was in a never ending loop. The other two
> processors went
> down to a low level of load around 10% or lower. Any activity
> like
> moving the timeline curser or opening a dialogue window caused
> the two
> low level processors to increase their activity a little.
>
> The only thing I found which changed this situation was to
> open a
> file-selection dialogue for importing a clip. This caused the
> 100%
> processor to swap with one of the other processors, so that a
> diff...

[Helen McCall (wildnfree)]

Hello Jonathan,

On Mon, 2009-07-27 at 16:47 -0500, Jonathan Thomas wrote:
> I just confirmed that under normal circumstances (i.e. not 100% CPU
> utilization) OpenShot seems to close just fine (no processes are still
> running after closing it) when launched from the sh script.

I can confirm this happens when the viewport has not frozen. Openshot
closes correctly and the console terminal window closes as well.

But if the viewport has frozen, and I quit from OpenShot, then the
console terminal is left behind after the OpenShot window has gone. And
the 100% cpu stays stuck at 100% until I kill the console terminal
window. This is why I think it is an orphan process.

> Let me ask a few more questions about the CPU:
>
> 1) Does the CPU only stay at 100% when playing (or seeking) the video?

No - there is usually one cpu at 100% whilst OpenShot is running. Any
activity at all causes the 100% load to switch to another cpu, or at
least causes a temporary dip in the load of the 100% cpu.

> 2) If you Pause the video (and wait a few seconds), does the CPU drop
> back down?

Yes it dips down for a second or two and then goes back to 100%

> 3) When the video freezes, will it unfreeze after a certain amount of
> time... if left alone?

No - I have left it a long time to see if it will unfreeze, and it
doesn't. Changing to another project does not unfreeze it either.

> On Mon, Jul 27, 2009 at 2:29 PM, Helen McCall
> <email address hidden> wrote:
> Hello Jonathan,
>
> Yes this still happens with 0.9.8 all installed from .deb
> packages. The
> only bit that I've had happening is the freezing of the
> viewport whilst
> playing. Still the same effects on System Monitor.
>
> One difference (caused I think by the different way of
> launching
> Openshot with a sh script) is that the process doesn't die
> when I kill
> OpenShot. I have to kill the terminal window as well before
> the 100%
> process dies.
>
> This is a menace because it is making it difficult for me to
> edit the
> circus film projects I am working on.
>
> I can reduce the chances of a freeze if I first drag the
> cursor all the
> way along the timeline before trying to play it. I have a
> niggling
> feeling that this has something to do with one of the length
> attributes.
> I was having so much trouble at first with the released form
> of 0.9.7
> and 0.9.8 that I didn't manage to log all the bugs that
> occurred, but
> several of them were giving error messages on the console
> relating to
> length attributes.
>
> The files I am working on for the circus project are all mp4
> files
> rendered by OpenShot from AVCHD clips from my camera. This
> technique was
> working fine until version 0.9.7 when the freezes became too
> prevalent.
> I was using 0.9.4 before that.
>
> Helen
>
>
>
>
> On Mon, ...

[Helen McCall (wildnfree)]

Hello Jonathan,

I have been doing some exhaustive testing on my problems here.

This bug appears to two different bugs.

The original one with your dog demo I think was something different from
the subsequent problems I was having with my mp4 clips from my circus
filming.

I have only been testing the problems with editing my circus mp4 clips.

I found that if I pre-processed my AVCHD in full 1920x1080 25p
resolution then I got the problems of freezing of the viewport quite
often. This happened with MP4, MOV, and AVI formats regardless.

If I pre-processed the AVCHD in 1440x1080 25p with the anamorphic pixel
aspect to give 16x9 aspect ratio, then I didn't have any problems with
freezing of the viewport.

I then inspected the AVCHD clips very carefully using VLC.

I spotted some very momentary glitches at the points where the viewport
could freeze sometimes in 1920x1080. I think I now know the cause of
these glitches.

When I bought my camera from Panasonic they supplied a class 4 SDHC
card, which the manual said was suitable. However class 4 SDHC is only
guaranteed up to 10 Mb/s. The camera's default data rate is 13 Mb/s, and
the high resolution rate is 17 Mb/s which I have been using. I now
believe that these glitches are probably caused by the camera's AVCHD
encoder being unable to write to the card fast enough to keep up with
the flow when a particularly fast movement is recorded.

I am going to get a class 6 SDHC card and test this hypothesis. It is
worth doing because OpenShot renders 1920x1080 beautifully, and it looks
so much better than 1440x1080 anamorphic resolution.

In the meanwhile I am going to have to do all my circus movies, and my
testing of OpenShot using the 1440x1080 16:9 anamorphic profile.

It might be worth us discussing the problem with Dan Dennedy when I have
done the tests with a class 6 card. What do you think?

Incidentally; I have found that OpenShot is the only software I can use
on Linux which plays QuickTime movies complete with the sound. Even VLC
fails to play the sound channels in QuickTime movies.

Best Wishes, Helen

On Mon, 2009-07-27 at 22:38 +0000, Helen McCall wrote:
> Hello Jonathan,
>
>
> On Mon, 2009-07-27 at 16:47 -0500, Jonathan Thomas wrote:
> > I just confirmed that under normal circumstances (i.e. not 100% CPU
> > utilization) OpenShot seems to close just fine (no processes are still
> > running after closing it) when launched from the sh script.
>
> I can confirm this happens when the viewport has not frozen. Openshot
> closes correctly and the console terminal window closes as well.
>
> But if the viewport has frozen, and I quit from OpenShot, then the
> console terminal is left behind after the OpenShot window has gone. And
> the 100% cpu stays stuck at 100% until I kill the console terminal
> window. This is why I think it is an orphan process.
>
>
> > Let me ask a few more questions about the CPU:
> >
> > 1) Does the CPU only stay at 100% when playing (or seeking) the video?
>
> No - there is usually one cpu at 100% whilst OpenShot is running. Any
> activity at all causes the 100% load to switch to another cpu, or at
> least causes a temporary dip in the load of the 100% cpu.
>
...

[Helen McCall (wildnfree)]

I have linked this bug to question 78804

I am attaching a screenshot of my system monitor showing start up and idle of OpenShot 0.9.13 on Ubuntu 9.04 amd64 with triple core Phenom processor.

Helen McCall

[TJ (tj)]

I was able to reproduce this and determine which thread is spinning.

New project, add one clip (AVCHD H.264 MPEG-TS 24mbps from Canon HF11). Put clip in Track #1. Drag time-cursor back and forth in the time-line until one core of the CPU hits 100% and stays there.

This happens whether or not audio is muted.

At the same time in a terminal I ran:

ps -em -o pcpu,lwp,stat,pid,tid,class,psr,wchan,args

The output related to openshot is:

62.0 - - 13243 - - - - /usr/bin/python -m pdb /usr/bin/openshot
 0.4 13243 Sl+ - 13243 TS 0 futex_ -
 0.0 13252 Sl+ - 13252 TS 0 futex_ -
 0.0 13254 Sl+ - 13254 TS 0 futex_ -
 0.0 13255 Sl+ - 13255 TS 0 futex_ -
 0.0 13453 Sl+ - 13453 TS 1 futex_ -
 0.2 13454 Sl+ - 13454 TS 0 futex_ -
 0.0 13455 Sl+ - 13455 TS 0 poll -
63.0 13456 Rl+ - 13456 TS 0 - -
 0.0 13457 Sl+ - 13457 TS 0 futex_ -

Note lightweight thread #13456 at 63% (2 cores =100% so that's 1 core at least)

With openshot running under gdb debugging I then interrupted the process (Ctrl+C) and listed the threads and compared that output:

(gdb) infor threads

(gdb) info threads
  59 Thread 0x7f29971b6950 (LWP 13457) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  58 Thread 0x7f29a2ff0950 (LWP 13456) 0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
  57 Thread 0x7f29a11e6950 (LWP 13455) 0x00007f29bce76496 in *__GI___poll (fds=0x346a890, nfds=2, timeout=332)
    at ../sysdeps/unix/sysv/linux/poll.c:87
  56 Thread 0x7f29a1bec950 (LWP 13454) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  55 Thread 0x7f29979b7950 (LWP 13453) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  4 Thread 0x7f29a39f8950 (LWP 13255) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
  3 Thread 0x7f29a41f9950 (LWP 13254) 0x00007f29bd9b7c95 in pthread_join (threadid=139816613935440, thread_return=0x0)
    at pthread_join.c:89
  2 Thread 0x7f29b11ae950 (LWP 13252) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
* 1 Thread 0x7f29bddc26f0 (LWP 13243) sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85

Thread 58 in this case, so let's see where its at:

(gdb) thread 58
[Switching to thread 58 (Thread 0x7f29a2ff0950 (LWP 13456))]#0 0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
(gdb) bt
#0 0x00007f29ac63e1da in ?? () from /usr/lib/libasound.so.2
#1 0x00007f29ac5ff5c1 in ?? () from /usr/lib/libasound.so.2
#2 0x00007f29ac5ff9b7 in ?? () from /usr/lib/libasound.so.2
#3 0x00007f29ac63eb4a in ?? () from /usr/lib/libasound.so.2
#4 0x00007f29ac8c654c in ?? () from /usr/lib/libSDL-1.2.so.0
#5 0x00007f29ac89908e in ?? () from /usr/lib/libSDL-1.2.so.0
#6 0x00007f29ac8a0b77 in ?? () from /usr/lib/libSDL-1.2.so.0
#7 0x00007f29ac8e9e59 in ?? () from /usr/lib/libSDL-1.2.so.0
#8 0x00007f29bd9b73ba in start_thread (arg=<value optimized out>) at pthread_create.c:297
#9 0x00007f29bce7ffcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112...

[TJ (tj)]

After installing the libasound2 and SDL-1.2 dbgsym (debug symbol) packages

sudo apt-get install libasound2-dbgsym libsdl1.2debian-all-dbgsym

I've gathered more information on what the spinning thread is doing:

(gdb) bt
#0 0x00007f62548bf496 in *__GI___poll (fds=0x7f6238e0af20, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#1 0x00007f624470d64c in snd1_pcm_wait_nocheck (pcm=0x3ad4900, timeout=-1) at pcm.c:2361
#2 0x00007f624470d9b7 in snd1_pcm_write_areas (pcm=0x3ad4900, areas=0x7f6238e0b000, offset=0, size=512,
    func=0x7f624474c7b0 <ioplug_priv_transfer_areas>) at pcm.c:6640
#3 0x00007f624474cb4a in snd_pcm_ioplug_writei (pcm=0x3ad4900, buffer=<value optimized out>, size=512)
    at pcm_ioplug.c:561
#4 0x00007f62449d454c in ALSA_PlayAudio (this=0x7f62361b8790) at ../../src/audio/alsa/SDL_alsa_audio.c:325
#5 0x00007f62449a708e in SDL_RunAudio (audiop=<value optimized out>) at ../../src/audio/SDL_audio.c:215
#6 0x00007f62449aeb77 in SDL_RunThread (data=0x3b46800) at ../../src/thread/SDL_thread.c:202
#7 0x00007f62449f7e59 in RunThread (data=0x7f6238e0af20) at ../../src/thread/pthread/SDL_systhread.c:47
#8 0x00007f62554003ba in start_thread (arg=<value optimized out>) at pthread_create.c:297
#9 0x00007f62548c8fcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

[TJ (tj)]

Here's the function local parameters for the same stack-trace as #10:

(gdb) bt full
#0 0x00007f62548bf496 in *__GI___poll (fds=0x7f6238e0af20, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
 oldtype = 2
 result = <value optimized out>
#1 0x00007f624470d64c in snd1_pcm_wait_nocheck (pcm=0x3ad4900, timeout=-1) at pcm.c:2361
 revents = 1
 npfds = 1
 err = 1
 err_poll = 3
 __FUNCTION__ = "snd1_pcm_wait_nocheck"
#2 0x00007f624470d9b7 in snd1_pcm_write_areas (pcm=0x3ad4900, areas=0x7f6238e0b000, offset=0, size=512,
    func=0x7f624474c7b0 <ioplug_priv_transfer_areas>) at pcm.c:6640
 frames = 512
 avail = 1
 xfer = 0
 err = 0
 state = SND_PCM_STATE_RUNNING
#3 0x00007f624474cb4a in snd_pcm_ioplug_writei (pcm=0x3ad4900, buffer=<value optimized out>, size=512)
    at pcm_ioplug.c:561
No locals.
#4 0x00007f62449d454c in ALSA_PlayAudio (this=0x7f62361b8790) at ../../src/audio/alsa/SDL_alsa_audio.c:325
 status = <value optimized out>
 sample_len = -1
 sample_buf = (short int *) 0x341fd10
#5 0x00007f62449a708e in SDL_RunAudio (audiop=<value optimized out>) at ../../src/audio/SDL_audio.c:215
 audio = (SDL_AudioDevice *) 0x7f62361b8790
 stream = (Uint8 *) 0x341fd10 ""
 stream_len = 2048
 udata = (void *) 0x7f6236159d90
 fill = (void (*)(void *, Uint8 *, int)) 0x7f6244c41eb0 <sdl_fill_audio>
 silence = 0
#6 0x00007f62449aeb77 in SDL_RunThread (data=0x3b46800) at ../../src/thread/SDL_thread.c:202
---Type <return> to continue, or q <return> to quit---
 userfunc = (int (*)(void *)) 0x7f62449a6fd0 <SDL_RunAudio>
 userdata = (void *) 0x7f62361b8790
#7 0x00007f62449f7e59 in RunThread (data=0x7f6238e0af20) at ../../src/thread/pthread/SDL_systhread.c:47
No locals.
#8 0x00007f62554003ba in start_thread (arg=<value optimized out>) at pthread_create.c:297
 __res = <value optimized out>
 pd = (struct pthread *) 0x7f6238e0b950
 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6616810393000975223, 8392704, 0, 140060318191680,
        140059661446960, 6550538160249529481, 6550754494040401033}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0,
      0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
 not_first_call = <value optimized out>
 robust = <value optimized out>
#9 0x00007f62548c8fcd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#10 0x0000000000000000 in ?? ()
No symbol table info available.

[TJ (tj)]

It looks as if the application's sound output (read MLT: SDL) is supposed to be feeding data to the thread via a file-descriptor socket, but whilst this thread is polling the FD the thread delivering the data has stopped without telling this thread.

As I don't see this on other MLT-based apps such as kdenlive, maybe OpenShot is missing some signal handling code?

[Jonathan Thomas (jonoomph)]

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.

You should be able to call your copy of the XML file from the "melt" command line:
$ melt xml:Westley.xml

If the 100% CPU happens when using the "melt" command, this should be easy for Dan to jump into and debug. One more thing, the XML file will contain absolute paths to your example video file, and that needs to be changed to a relative path... and then all .zipped up.

If I just send Dan the debug output from above, he will certainly request an example for debugging reasons.

Thanks,
-Jonathan

[TJ (tj)]

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.

[TJ (tj)]

I've been able to reproduce this in my recent kdenlive build using the same MLT/ffmpeg libraries.

I'll be building the latest ffmpeg and MLT from HEAD later. If they appear to be stable and usable I'll re-test against the new MLT with openshot and kdenlive.

ps -em -o pcpu,lwp,stat,pid,tid,class,psr,wchan,args

 103 - - 20387 - - - - /usr/bin/kdenlive
 6.7 20387 Sl+ - 20387 TS 0 poll -
 0.0 20405 Sl+ - 20405 TS 1 futex_ -
 0.0 20406 Sl+ - 20406 TS 1 futex_ -
 0.0 20407 Sl+ - 20407 TS 0 futex_ -
 0.0 20408 Sl+ - 20408 TS 0 futex_ -
 1.2 20412 Sl+ - 20412 TS 0 futex_ -
 0.0 20449 Sl+ - 20449 TS 0 futex_ -
48.8 20450 Sl+ - 20450 TS 0 futex_ -
 0.5 20451 Sl+ - 20451 TS 0 poll -
61.0 20452 Rl+ - 20452 TS 1 - -
 1.1 20453 Sl+ - 20453 TS 1 futex_ -

Lightweight thread (LWP) 20452 is running, and pushing the CPU core to 61%. LWP 20450 is sleeping on a futex.

(gdb) ^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7f6001f7f750 (LWP 20387)]
0x00007f5ffdc41496 in *__GI___poll (fds=0x3bb60a0, nfds=5, timeout=299) at ../sysdeps/unix/sysv/linux/poll.c:87
87 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
        in ../sysdeps/unix/sysv/linux/poll.c

(gdb) info threads
  64 Thread 0x7f5fd180a950 (LWP 20453) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  63 Thread 0x7f5fd700e950 (LWP 20452) 0x00007f5ff101e390 in ?? () from /usr/lib/libpulse.so.0
  62 Thread 0x7f5fd200b950 (LWP 20451) 0x00007f5ffdc41496 in *__GI___poll (fds=0x621fbd0, nfds=2, timeout=332)
    at ../sysdeps/unix/sysv/linux/poll.c:87
  61 Thread 0x7f5fe03d3950 (LWP 20450) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  60 Thread 0x7f5fe0bd4950 (LWP 20449) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  23 Thread 0x7f5fd680d950 (LWP 20412) pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:217
  19 Thread 0x7f5fdebd0950 (LWP 20408) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  18 Thread 0x7f5fde3cf950 (LWP 20407) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  17 Thread 0x7f5fdfbd2950 (LWP 20406) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
  16 Thread 0x7f5fdf3d1950 (LWP 20405) pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
* 1 Thread 0x7f6001f7f750 (LWP 20387) 0x00007f5ffdc41496 in *__GI___poll (fds=0x3bb60a0, nfds=5, timeout=299)
    at ../sysdeps/unix/sysv/linux/poll.c:87

(gdb) thread 63
[Switching to thread 63 (Thread 0x7f5fd700e950 (LWP 20452))]#0 0x00007f5ff101e390 in ?? ()
   from /usr/lib/libpulse.so.0
(gdb) bt
#0 0x00007f5ff101e390 in ?? () from /usr/lib/libpulse.so.0
#1 0x00007f5fe18edb48 in ?? () from /usr/lib/alsa-lib/libasound_module_pcm_pulse.so
#2 0x...

[Jonathan Thomas (jonoomph)]

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!
>
> S...

[TJ (tj)]

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.

This could be more to do with the lack of correct seek support for AVCHD
H.264 MPEG-TS in ffmpeg.

I've been in correspondence with Ivan Schreter about his recent seek
patches added to ffmpeg, since when I tried them they totally broke
playback of Canon HF11 MTS files PF24-in-60i encoding. He developed them
against his Panasonic camera's MTS recordings.

My current ffmpeg package is from the ffmpeg git prior to Ivan's patches
because they made the system unusable.

I'll see if there's any improvement with the latest HEAD.

[TJ (tj)]

Using MLT:

commit 35d237661cb43067ed38fbc1605f4144be0ec431
Merge: 75ed0b3... 763ddda...
Author: gmarco <email address hidden>
Date: Tue Sep 1 20:40:33 2009 +0200

The issue still occurs.

Dan Dennedy (MLT) is aware of some A/V sync issues with AVCHD that step from the problems with ffmpeg that I mentioned.

I'll keep an eye on the ffmpeg patches since Dan can't add improved seek to MLT until they're working correctly.

[Helen McCall (wildnfree)]

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.
>

[Helen McCall (wildnfree)]

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, t...

[Jonathan Thomas (jonoomph)]

I'll be watching the MLT mailing list for an update on this. I've seen a
few emails bouncing around about this topic.

On Wed, Sep 2, 2009 at 3:56 PM, TJ <email address hidden> wrote:

> Using MLT:
>
> commit 35d237661cb43067ed38fbc1605f4144be0ec431
> Merge: 75ed0b3... 763ddda...
> Author: gmarco <email address hidden>
> Date: Tue Sep 1 20:40:33 2009 +0200
>
> The issue still occurs.
>
> Dan Dennedy (MLT) is aware of some A/V sync issues with AVCHD that step
> from the problems with ffmpeg that I mentioned.
>
> I'll keep an eye on the ffmpeg patches since Dan can't add improved seek
> to MLT until they're working correctly.
>
> --
> 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
>

[Jonathan Thomas (jonoomph)]

Quick question. Does this issue only happen when using AVCHD video clips?

[Helen McCall (wildnfree)]

No - it has happened with MP4 codec as well.

Helen

On Sat, 2009-09-12 at 02:48 +0000, Jonathan Thomas wrote:
> Quick question. Does this issue only happen when using AVCHD video
> clips?
>

[Jonathan Thomas (jonoomph)]

Helen, what is your mp4 file encoded as? mpeg4? I only ask because mp4 can
also contain h.264... which is AVCHD.

Thanks,
-Jonathan

On Fri, Sep 11, 2009 at 10:17 PM, Helen McCall
<email address hidden>wrote:

> No - it has happened with MP4 codec as well.
>
> Helen
>
>
> On Sat, 2009-09-12 at 02:48 +0000, Jonathan Thomas wrote:
> > Quick question. Does this issue only happen when using AVCHD video
> > clips?
> >
>
> --
> 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
>

[Helen McCall (wildnfree)]

Hello Jonathan,

Sorry I didn't make it clear. The codec was mp4 in an mp4 format. The
others I tried were h.264 in an mp4 file format, and h.264 in an MTS
format. All three of these gave the same problem. (and still do)

I have also experienced the same problem with the latest version of
kdenlive from TJ's ppa. I have only tested kdenlive with mp4 codec in
mp4 format, and h.264 codec in MTS format. I used the same clips in both
OpenShot and kdenlive.

The earlier version of kdenlive which comes with Ubuntu wouldn't work at
all with my MTS files.

I think the problem must be with mlt or ffmpeg. TJ's debugger also
pointed to that.

Best wishes, Helen

On Sat, 2009-09-12 at 21:31 +0000, Jonathan Thomas wrote:
> Helen, what is your mp4 file encoded as? mpeg4? I only ask because mp4 can
> also contain h.264... which is AVCHD.
>
> Thanks,
> -Jonathan
>
> On Fri, Sep 11, 2009 at 10:17 PM, Helen McCall
> <email address hidden>wrote:
>
> > No - it has happened with MP4 codec as well.
> >
> > Helen
> >
> >
> > On Sat, 2009-09-12 at 02:48 +0000, Jonathan Thomas wrote:
> > > Quick question. Does this issue only happen when using AVCHD video
> > > clips?
> > >
> >
> > --
> > 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
> >
>

[Helen McCall (wildnfree)]

I thought I would add this link to Daniel Chen's blog on the Audio Stack
problems in Jaunty. This might be part of the problem.

http://drowninginbugs.blogspot.com/2009/02/pulseaudio.html

Helen

On Sat, 2009-09-12 at 22:10 +0000, Helen McCall wrote:
> Hello Jonathan,
>
> Sorry I didn't make it clear. The codec was mp4 in an mp4 format. The
> others I tried were h.264 in an mp4 file format, and h.264 in an MTS
> format. All three of these gave the same problem. (and still do)
>
> I have also experienced the same problem with the latest version of
> kdenlive from TJ's ppa. I have only tested kdenlive with mp4 codec in
> mp4 format, and h.264 codec in MTS format. I used the same clips in both
> OpenShot and kdenlive.
>
> The earlier version of kdenlive which comes with Ubuntu wouldn't work at
> all with my MTS files.
>
> I think the problem must be with mlt or ffmpeg. TJ's debugger also
> pointed to that.
>
> Best wishes, Helen
>
>
>
> On Sat, 2009-09-12 at 21:31 +0000, Jonathan Thomas wrote:
> > Helen, what is your mp4 file encoded as? mpeg4? I only ask because mp4 can
> > also contain h.264... which is AVCHD.
> >
> > Thanks,
> > -Jonathan
> >
> > On Fri, Sep 11, 2009 at 10:17 PM, Helen McCall
> > <email address hidden>wrote:
> >
> > > No - it has happened with MP4 codec as well.
> > >
> > > Helen
> > >
> > >
> > > On Sat, 2009-09-12 at 02:48 +0000, Jonathan Thomas wrote:
> > > > Quick question. Does this issue only happen when using AVCHD video
> > > > clips?
> > > >
> > >
> > > --
> > > 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 t...

[Pako (elektrobank01)]

Same here with 1.2.2 in Maverick. when Idle is 22% + 7% for Pulseaudio and 116 MiB Ram, with 1920x1080p h264 on timeline it goes to 100%

[Berg (emil-berg91)]

Is this bug still in progress? It's a bit irritating that you can't view a still picture of a paused movie without the CPU at almost 100 %.

[Andy Finch (fincha)]

I thought it had been sorted out, but maybe not. Is it maybe more to do with getting multithreading with MLT working?

[Jonathan Thomas (jonoomph)]

MLT causes the high CPU and not OpenShot. So, there is nothing the OpenShot developers can do about it, until we replace MLT with our own framework. Which is coming soon. Thanks.

[Myung (caroline-caillot)]

Hi,

If only I had seen this before doing my movie, I would have found another soft ! I just finished the video and can't export cos my CPU can not handle it :-(
Hope you can fix this one day!

[Olivier Girard (eolinwen)]

You turn on this issue converting before your files in a format less gluton like DNxHD converting with for sample EnKodeur-Mixeur. If you want to use h264 files. Same things in the output format and convert them in h264 HD with the same tool.