Dragging video to timeline eats RAM

Confirmed. Resident memory usage hit 11GB within 2 seconds here. It happens as soon as you start dragging the file, and not when you drop it on the timeline.

Correction: it happens when you drag the video over the timeline, but before you release the mouse button.

Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/openshot/windows/MainGTK.py", line 1160, in
 motion_cb
    self.motion_file_drag(wid, context, x, y, time)
  File "/usr/lib/pymodules/python2.7/openshot/windows/MainGTK.py", line 1223, in
 motion_file_drag
    self.new_clip = self.new_clip_object.RenderClip()
  File "/usr/lib/pymodules/python2.7/openshot/classes/clip.py", line 1255, in Re
nderClip
    pixbuf_list = self.parent.parent.split_images(middlePixBuf, imgTrack_Left_He
ight, int(Size_Of_Middle))
  File "/usr/lib/pymodules/python2.7/openshot/classes/sequences.py", line 772, i
n split_images
    new_pixbuf = pixbuf.scale_simple(chunk_size, height, gtk.gdk.INTERP_NEAREST)
KeyboardInterrupt

...

==22891== 1,129,040,000 bytes in 5,132 blocks are still reachable in loss record
 16,823 of 16,823
==22891== at 0x4C296CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64
-linux.so)
==22891== by 0x9A35C04: gdk_pixbuf_new (in /usr/lib/x86_64-linux-gnu/libgdk_p
ixbuf-2.0.so.0.2500.0)
==22891== by 0x9A3CE36: gdk_pixbuf_scale_simple (in /usr/lib/x86_64-linux-gnu
/libgdk_pixbuf-2.0.so.0.2500.0)
==22891== by 0x8AF8475: ??? (in /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/_gtk.so)
==22891== by 0x4B65C8: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==22891== by 0x4B6DB6: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==22891== by 0x4BCD4C: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==22891== by 0x4B6A99: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==22891== by 0x4B6DB6: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==22891== by 0x4BCD4C: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==22891== by 0x44908E: ??? (in /usr/bin/python2.7)
==22891== by 0x41AE39: PyObject_Call (in /usr/bin/python2.7)

This is happening because openshot thinks the clip is approximately 2.5 years long.
Clip() constructor is being called with end_time = 71654371.0216 (seconds, ie 800 days)

So what happens if you double click the clip while it is in the project files tree?

Can you follow the guide here:

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

Hopefully from that we can find out whether the problem can be traced to either ffmpeg or MLT.

What is the source of this file? I've tried it on Openshot 1.4.2 and it doesn't eat all the memory, it gets imported as a zero length file.

MLT (melt) shows the message "[matroska @ 0x8620be0]Estimating duration from bitrate, this may be inaccurate".

FFMpeg shows:

[matroska @ 0x91680e0]Unknown entry 0xFF
    Last message repeated 3 times
[matroska @ 0x91680e0]Estimating duration from bitrate, this may be inaccurate
Input #0, matroska, from 'openshot_test.mkv':
  Metadata:
    doctype : matroska
  Duration: 00:00:00.00, start: 0.000000, bitrate: N/A
    Stream #0.0(eng): Audio: flac, 44100 Hz, 2 channels, s16
    Metadata:
      title : Audio
    Stream #0.1(eng): Video: h264, yuv420p, 1366x768 [PAR 1:1 DAR 683:384], 25 fps, 25 tbr, 1k tbn, 1073741824.00 tbc
    Metadata:
      title : Video
  19.66 A-V: 0.013 s:0.0 aq= 289KB vq= 1399KB sq= 0B f=0/493 0/0

I use Linux Mint 11, MLT 0.7.6, FFMpeg 0.6.4.

Whatever authored the mkv file is probably at fault, it looks to have generatde a bad file, FFMpeg can't determine the length.

12.04 includes an old version (just for a change) of MLT (0.7.4), the situation might improve if the latest version is used. Or it might be due to changes in FFMpeg since 0.6.4, it's difficult to tell.

This error is happening because libmlt is claiming that the video file is -1 frames long. That is, self.p.get_length() in the thumbnailer is returning 0x7fffffff for this file. Suggest perhaps an assert(self.p.get_length() < 0x7fffffff) in the thumbnailer, this causes openshot to gracefully reject the file. I also made a small test script as follows:

import mlt

p = mlt.Producer(mlt.Profile('quarter_ntsc'), 'openshot_test.mkv')
print p.get_length()

This segfaults with no output.

Is this with version 0.7.4 of MLT? Can you try with 0.7.6, available when you add this PPA:

sudo add-apt-repository ppa:sunab/kdenlive-release

Ok so it looks like the issue with the duration is bug 925238 in kazam which is fixed in trunk.

I was using limblt 0.7.6

ii libmlt4 0.7.6+git20111 multimedia framework (runtime)

same.
0.7.6+git20111222-1

Try to test with the last version of MLT (0.7.7)
See here how to get the last : https://answers.launchpad.net/openshot/+faq/1861

libavcodec53 4:0.8-1ubuntu2~ppa~precise4
libavdevice53 4:0.8-1ubuntu2~ppa~precise4
libavformat53 4:0.8-1ubuntu2~ppa~precise4
libavutil51 4:0.8-1ubuntu2~ppa~precise4

It seems to be an 'old ' version of FFmpeg, try to add this PPA : https://launchpad.net/~jon-severinsson/+archive/ffmpeg
The last version out of FFmpeg is the 0.10

However, there aren't the only to be old : even goocanvas seems to be a old version and can explain to this issue
libgoocanvas-common 0.15-1
libgoocanvas3 0.15-1
python-pygoocanvas 0.14.1-1ubuntu6
The last is the 2.05 (if my memory is yet good).