previewing effect of video edits causes Openshot + Desktop to freeze

[Charlie Shaw]

Openshot 1.4.3 installed via PPA under Ubuntu 11.10 as per guide on Openshot website.

Initial messages on start-up:

charlie@fiona-ubuLenovo-3000-G530:~$ openshot ./Pictures/100CASIO/CIMG1113.AVI &[1] 5498
charlie@fiona-ubuLenovo-3000-G530:~$
------------------------- ERROR 1 ------------------------------
Failed to import 'from openshot import main'
Error Message: cannot import name main
----------------------------------------------------------------
--------------------------------
   OpenShot (version 1.4.3)
--------------------------------
Process no longer exists: 5295. Creating new pid lock file.
Adding files to the watch queue:
/home/charlie/Pictures/100CASIO/CIMG1113.AVI

Detecting formats, codecs, and filters...
:
:
etc...

application seems to load / run.

Use the Resize tool to shorten the AVI file loaded above (size is approx 13MBytes, generated by a Casio ZX-60 camera); resizing is successful and modified AVI file can be saved as mp4, replayed with eg Movie.

BUT: if I use the 'preview' button to check result of the re-size before saving/exporting the video file, the Openshot GUI locks up.

Moving mouse to left of screen to 'activate' 'Dash' launcher has no effect; Alt-Tab has no effect (there are other apps running).

Ctrl-Alt-F2 DOES bring up a console where root can login; Python/Openshot are NOT taking an excessive amount of CPU (virtually none..).

kill -9 'pid of Openshot' restores normal system function.

[Andy Finch (fincha)]

The first thing you should do is check this FAQ (especicially the parts regarding seeking):

https://answers.launchpad.net/openshot/+faq/983

What version of MLT is on your system? There was a memory leak that is fixed in v0.8.2, if you're not using that try upgrading to that version.

Are all your avi files from the same source? Does the same thing happen with all of them?

[Charlie Shaw (n2924-dotcom)]

Output from ffplay included below FTR, but please note that this is a bug report concerning Openshot UI (or is it technically a GNOME UI ??, so this bugzilla entry belongs elsewhere?), rather than an issue with generating / replaying specific files (ffplay and melt and totem all replay the file exported from Openshot correctly; melt allows me to step forward/backward 1 frame at a time and check the exact end frame of the exported video; still awaiting reports re correct re-play on non-Linux machines).

I have a number of video files from the same camera; will check if similar behaviour occurs with others.

I have an alternative camera that may produce a different format file, will investigate whether that makes any difference.

melt / libmlt4 are both at version 0.7.4-3 which is the latest / only offered by the Ubuntu repositories for oneiric & also the .deb files on pkgs.org

I can see the source files for melt 0.8.2 on sourceforge...

Is there a 'safe' way to download / build the 0.8.2 versions of melt / libmlt on my only (and shared, so I am in trouble if it breaks..) machine here ? (I am currently trying this for another video programme, and am currently blocked by a dependency conflict, where the programme to be tested needs precise versions that are older than what is currently on the system).

ffplay -i info for the ORIGINAL file from camera (ie that is imported to Openshot):

ffplay -i ./Pictures/100CASIO/CIMG1113.AVI
ffplay version 0.7.6-4:0.7.6-0ubuntu0.11.10.1, Copyright (c) 2003-2011 the Libav developers
  built on Jun 12 2012 16:28:10 with gcc 4.6.1
  configuration: --extra-version='4:0.7.6-0ubuntu0.11.10.1' --arch=i386 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static
  WARNING: library configuration mismatch
  avutil configuration: --extra-version='4:0.7.6ubuntu0.11.10.1+medibuntu1' --arch=i386 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-version3 --enable-vaapi --enable-libopenjpeg --enable-libfaac --enable-nonfree --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdirac --enable-libmp3lame --enable-librtmp --enable-libx264 --enable-libxvid --enable-libopencore-amrnb --enable-version3 --enable-libopencore-amrwb --enable-version3 --enable-libvo-aacenc --enable-version3 --enable-libvo-amrwbenc --enable-version3 --enable-libdc1394 --shlibdir=/usr/lib/i686/cmov --cpu=i686 --enable-shared --disable-static --disable-ffmpeg --disable-ffplay
  avcodec configuration: --extra-version='4:0.7.6ubuntu0.11.10.1+medibuntu1' --arch=i386 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-p...

[Andy Finch (fincha)]

Sorry, I think you misunderstood - the point is to check your *source* files with ffplay/melt. As the ffmpeg libraries & MLT provide the format & seeking support for OpenShot, we need to identify if they can handle the files properly first (the seeking is important as you are trimming your file, rather than just simply playing it back). If they have a problem with your source files, then OpenShot will too.

The latest MLT is available in a PPA, ppa:sunab/kdenlive-release. This will only work with OpenShot 1.4.3 & above.

[Charlie Shaw (n2924-dotcom)]

As per earlier post,

################### clip ######################
ffplay -i info for the ORIGINAL file from camera (ie that is imported to Openshot):

ffplay -i ./Pictures/100CASIO/CIMG1113.AVI
ffplay version 0.7.6-4:0.7.6-0ubuntu0.11.10.1, Copyright (c) 2003-2011 the Libav developers
  built on Jun 12 2012 16:28:10 with gcc 4.6.1
:
:
Input #0, avi, from './Pictures/100CASIO/CIMG1113.AVI':
  Metadata:
    creation_time : 2012-10-07/ 08:40
    encoder : CASIO EX-Z60
  Duration: 00:00:45.77, start: 0.000000, bitrate: 2282 kb/s
    Stream #0.0: Video: mjpeg, yuvj420p, 320x240, 14.99 tbr, 14.99 tbn, 14.99 tbc
    Stream #0.1: Audio: adpcm_ima_wav, 11025 Hz, 1 channels, s16, 44 kb/s
############### end clip #######################

Thanks for the reference to the ppa for latest MLT version; have installed that, see below for detail.

IF Openshot is started in the back-ground with &, behaviour is as described earlier.

Tried starting Openshot as the foreground process, FOR ONE OUT OF 2 TRIALS then only the 'video seek' controls are frozen; was able to minimize the Openshot window, bring a terminal window to the foreground, and check process state.

Need to repeat this trial a few times (takes time), trying to ensure that exactly the same set of key press / commands / clicks etc is used each time to eliminate variation in them as a cause.

Here are last few lines printed by Openshot (started as foreground, the 1 time it did not completely freeze) as I re-sized the clip and tried to preview, then escaped the 'lock-up': (NOTE, I have not defined a project for these trials).

state saved
on_btnZoomIn_clicked
on_btnZoomIn_clicked
set_preview_mode
set_view_mode
project state modified
state saved
set_preview_mode
set_view_mode
project state modified
state saved
set_preview_mode
set_view_mode
project state modified
state saved
set_preview_mode
set_view_mode
project state modified
state saved
on_tlbPlay_clicked called with self.GtkToolButton
^Z
[1]+ Stopped openshot ./Pictures/100CASIO/CIMG1113.AVI
charlie@fiona-ubuLenovo-3000-G530:~$ bg 1
[1]+ openshot ./Pictures/100CASIO/CIMG1113.AVI &
charlie@fiona-ubuLenovo-3000-G530:~$ ps -elF |grep 'openshot'
0 S charlie 1942 1 1 80 0 - 180475 poll_s 201244 0 08:57 ? 00:05:47 /usr/lib/firefox/firefox https://answers.launchpad.net/openshot/+faq/983
0 S charlie 6256 2023 41 80 0 - 93888 poll_s 128760 0 15:16 pts/0 00:01:28 /usr/bin/python /usr/bin/openshot ./Pictures/100CASIO/CIMG1113.AVI
0 S charlie 6287 2023 0 80 0 - 1055 pipe_w 772 0 15:19 pts/0 00:00:00 grep --color=auto openshot
charlie@fiona-ubuLenovo-3000-G530:~$ kill -9 6256
charlie@fiona-ubuLenovo-3000-G530:~$
[1]+ Killed openshot ./Pictures/100CASIO/CIMG1113.AVI

################################################################################

What you do NOT see on the console log above is the 'pause' button legend that is 'stuck' in the middle of the screen: see attached screenshot.

Dunno if it is relevant, but extra/changed message at openshot start-up after upgrading MLT:

charlie@fiona-ubuLenovo-3000-G530:~$
------------------------- ERROR 1 ----------------------------...

[Charlie Shaw (n2924-dotcom)]

OK; procedure to replicate this UI lock-up is now very easy and I think proves it is not related to input file format:

Start Openshot from command line using

openshot test_file &

IMMEDIATELY press 'Preview play' button (even though the clip thumbnail has not been dropped onto the timeline).

The 'slider button' jumps almost immediately to right hand end of travel; depending on whether mouse is still hovering over the Play/Pause button you may see the Play/Pause legend flash briefly.

MOST of the time, from this point on, 'Desktop / UI' lock up is as described earlier; on one occasion so far I have been able to re-wind using the 'seek to start' button a couple of times, but then produced the lock-up as described by dropping the clip on the timeline, and shortenning the clip using the Resize tool.

Using Ctrl-Alt-F2 to open a root console window, you can see about 8% of CPU is used, AND I think a gradually increasing amount of memory (will leave it running a while to check).

[Andy Finch (fincha)]

I've tried this a number of times (using your AVI file) and I don't experience any freezing of the desktop. The problem I do see is that the file isn't added to OpenShot.

[Charlie Shaw (n2924-dotcom)]

Not sure what is meant by 'file isn't added to Openshot ' , but...

1. is it possible to verify that your test machine has the same characteristics as mine, in terms of 64/32 bit, Python library versions, etc...

2. is there a way to get this test case tried out on a number of different machines with different characteristics ??

CPU I am using is:

cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Celeron(R) CPU 900 @ 2.20GHz
stepping : 10
cpu MHz : 2194.540
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc up arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm xsave lahf_lm dtherm
bogomips : 4389.08
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

3. I have been experimenting with Python debug / analysis tools ( I am a complete beginner @ Python); by using the command line

 python -m trace --trace /usr/bin/openshot >python_trc.log 2>&1

I get a trace of every statement executed upto the point where I kill the process (for some reason, if you pass the name of the input file on the command line, Openshot does not start..).

Last 1,000 lines of a 600MByte log file are attached; it shows that the code is in a repetitive loop, dependent on things like whether pre-view is paused, and clip length, etc, etc..
      Maybe someone who is practiced in the art of reading Python code can review this, paying special attention to what happens if clip length has 'unexpected values', due to, for example, no clip being 'on the timeline'; or clip has been re-sized...

4. maybe this is really a Python bug...when I kill the process as started above, then switch back to the non-root console with Ctrl-Alt-F7, the logged in user session appears to be 'rebooted / re-started' (you see some process stop/start messages like when the PC boots/shuts down; then the log-in screen appears)....this does not happen in the the python -m trace option is not used..

5. NB: I have used the above method twice (first time was not redirecting the trace output to a log file); 1st time, I had to 'File > Import' the CIMG.AVI file, BUT 2nd time the AVI file was already 'visible' as a thumbnail... this does NOT happen when the python -m trace facility is NOT used ...

FWIW, IMHO, there is a race or hazard somewhere, which is why symptoms vary slightly on my machine, and so far do not appear on your machine.

[Andy Finch (fincha)]

"Not sure what is meant by 'file isn't added to Openshot "

By that, I mean the file isn't visible in the project files tree or the timeline.

1. is it possible to verify that your test machine has the same characteristics as mine, in terms of 64/32 bit, Python library versions, etc...

I run Linux Mint 13 (32 bit).

2. is there a way to get this test case tried out on a number of different machines with different characteristics ??

Only if others with different machines decide to chime in - I only have 1 machine.

I tried adding your clip to OpenShot in the normal way, i.e. adding the file via the Import Files menu item, and the clip plays ok after being trimmed, so I would say use that to workaround the issue you are having.

[Charlie Shaw (n2924-dotcom)]

Thanks for the clarifications, but 'File > Import' is not a work-around (see below).

The (potential) hardware & real software differences between our respective platforms could be responsible for the 'hard or impossible to reproduce' behaviour that you are seeing; as well as the difficulty of reproducing the exact sequence of 'input commands' (see below).

Is there a way to bring this thread to the attention of other devs who have access to at least a Ubuntu 11.10 environment ?

As mentioned earlier, doing a 'File > Import' of the clip, then re-size, then play will reproduce the bug on my machine 'pretty reliably'.

'Exact sequence of input commands':

- a more precise description of how I resize is:

1. File > Import the mp4 clip (length about 11 seconds).
2. drag/drop thumbnail onto the timeline, starting at 0
3. Expand the timeline scale to maximum (1 second).
4. drag the red 'cursor' to the 8 second position (ie mark desired end point of clip)
5. click 'resize' button.
6. scroll timeline right until end of (original) clip is visible
7. drag end of clip to somewhere 'just to the right' of the red cursor (just to the left also results in this issue).
8. click 'rewind to start' button.
9. click 'Play'; allow to play to new end point
10. drag red cursor back/left by 3 seconds
11. repeat steps 9 & 10

Following these steps, I get a lock-up sometimes after the 2nd click of 'Play' (ie 'immediately'), sometimes I have to iterate several times (max seems about 6 so far). Very occasionally I get the Play or Pause button legend 'stuck' on the display and am able to activate the terminal window as the logged in user (rather than having to use Ctrl-Alt-F2 to activate a 2nd console).

SO there is either some other element not described above eg exact mouse pointer trajectory / timing; timing between clicks; location of hover whilst clip playing; exact position of end of re-sized clip etc that is needed to reproduce this issue reliably.... or this 'randomness' is a reflection of the hazard that may be responsible for this bug..

[Launchpad Janitor (janitor)]

[Expired for OpenShot Video Editor because there has been no activity for 60 days.]