Extending last clip in timeline is extremely slow.

[tercerapersona]

First of all, this app is great! a miracle in Linux.

Say you import a long length video, it's difficult to set an start/end point in the Source preview, so I choose an approx range and move it to the Timeline to zoom in. When extending any of the (start/end) extremes far away from what I've previously chosen it gets buggy.

Sorry but I couldn't make an account in the forum to disscuss these, 1) It would be great to select multiple clips in the timeline, in order to move/delete them all. 2) Do you have any plan to use a less quality video proxy in the preview to make editing fast? I believe the actual way to improve perfomance is setting Interpolation to Nearest Neighbor 3) Do you think it would be better (and technically easy) to split video/audio into different tracks?

[ghost]

Could you be more specific? What happens when you say it gets buggy? Attempting to reproduce this for myself just makes it more difficult to work with. I wouldn't know when or if it becomes buggy because I don't know what I should be looking for.

As for your questions and suggestions, I don't think it would be my place to answer them directly, but I could pass them along for you.

[ddennedy]

Thank you for your feedback, but "it gets buggy" is not a valid bug report.

[ddennedy]

1) maybe some day, but multiple selection has a lot of weird usability corner cases too 2) no plan at this time. The plan is to make GPU processing more viable. You might consider to transcode everything to a fast and edit friendly intermediate file format that is lossless or near lossless. 3) We already have audio and video tracks. You can disable the audio on a video track or on a per-clip basis and place videos with audio (including a previously used one) on an audio track. If you are asking about automatically put only video on a video track and a cliip's audio on audio track when adding a clip to timeline, that might be an option someday.

[tercerapersona]

Thanks for reply and sorry for being short, but I though that just trying to reproduce it you were able to see it. Here's what's happens to me, https://dl.dropboxusercontent.com/u/30076751/shotcut--extend-timeline-bug.mp4 I can't do anything then, although it doesn't crash my computer gets unusably slow

[ddennedy]

That link gives a 404 error, and this is the Shotcut project, which is not the same as OpenShot.

[tercerapersona]

yes, I confused the name, fixed it, and pasted the previous clipboard. note on the video: when I click on the right edge of the clip I'm still dragging it, I never release the left mouse button

[ddennedy]

Ok, I see it now. On my Windows and OS X systems, this operation is smooth and fast. On my Linux system, which is no modest PC and runs Linux on bare metal including OpenGL on the GPU (OpenGL is used for Timeline UI), I also experience this slow behavior. However, we use a high level UI technology for drawing the Timeline (Qt Quick), which puts many things outside of our control. We do not make OS-specific code for this, and it seems to be something specific to Linux. I am willing to re-open this as a Linux-specific problem, but it might not get much attention. :-S

[tercerapersona]

I understand! Thanks for the feedback

[ddennedy]

A workaround is to copy the clip to the Source player, switch to the Source player, adjust the out point there (using the play back controls and 'O' keyboard shortcut is more convenient than dragging the trim controls), and then overwrite the last clip on the correct track of the timeline.

[tercerapersona]

That's fine. When I copy the clip to the Source, it's the full video again but in/out range selected. I can edit and move it to the timeline again.

Is there any shortcut or control to step by keyframe instead of frame (as in Avidemux)?, that would be nice! (if it's rather easy to implement)

[metellius]

Reproduced and had a look in gdb; think I see what's happening. For every mousemove event this happens (this is a reversed backtrace for readability):

#161 0x00000000004562e6 in main (argc=1, argv=0x7fffffffd7e8) at main.cpp:250
    [,,,]
#148 0x00007ffff546b265 in QGuiApplicationPrivate::processWindowSystemEvent (e=0x6080006aeea0) at kernel/qguiapplication.cpp:1581
    [...]
#117 0x00007ffff5f8eb5c in QQuickMouseArea::positionChanged (this=0x603001945030, _t1=0x7fffffffb460) at .moc/moc_qquickmousearea_p.cpp:563
    [ lots of qml engine stuff, comes back to cpp in timelinedock ]
#69 0x00000000006d0eb1 in TimelineDock::qt_static_metacall (_o=0x6110000e7f80, _c=QMetaObject::InvokeMetaMethod, _id=35, _a=0x7fffffff67c0) at moc_timelinedock.cpp:363
#68 0x000000000062b52f in TimelineDock::trimClipOut (this=0x6110000e7f80, trackIndex=0, clipIndex=0, delta=1, ripple=false) at docks/timelinedock.cpp:740
#67 0x0000000000605083 in MultitrackModel::trimClipOut (this=0x6110000e7fe8, trackIndex=0, clipIndex=0, delta=1, ripple=false) at models/multitrackmodel.cpp:621
#66 0x00000000006cf6ed in MultitrackModel::modified (this=0x6110000e7fe8) at moc_multitrackmodel.cpp:515
#65 0x00007ffff47ea9dc in QMetaObject::activate (sender=0x6110000e7fe8, m=0xa3aa20 <MultitrackModel::staticMetaObject>, local_signal_index=3, argv=0x0) at kernel/qobject.cpp:3578
#64 0x00007ffff47eb1f2 in QMetaObject::activate (sender=0x6110000e7fe8, signalOffset=26, local_signal_index=3, argv=0x0) at kernel/qobject.cpp:3713
#63 0x00000000006d1cd6 in TimelineDock::qt_static_metacall (_o=0x6110000e7f80, _c=QMetaObject::InvokeMetaMethod, _id=55, _a=0x7fffffff6150) at moc_timelinedock.cpp:384
#62 0x0000000000626fd7 in TimelineDock::clearSelectionIfInvalid (this=0x6110000e7f80) at docks/timelinedock.cpp:372
#61 0x0000000000625c6d in TimelineDock::setSelection (this=0x6110000e7f80, newSelection=..., trackIndex=-1, isMultitrack=false) at docks/timelinedock.cpp:260
#60 0x0000000000629de0 in TimelineDock::emitSelectedFromSelection (this=0x6110000e7f80) at docks/timelinedock.cpp:611
#59 0x00000000006d3ccc in TimelineDock::selected (this=0x6110000e7f80, _t1=0x604000d96c90) at moc_timelinedock.cpp:644
#58 0x00007ffff47ea9dc in QMetaObject::activate (sender=0x6110000e7f80, m=0xa3ac20 <TimelineDock::staticMetaObject>, local_signal_index=10, argv=0x7fffffff5cc0) at kernel/qobject.cpp:3578
#57 0x00007ffff47eb1f2 in QMetaObject::activate (sender=0x6110000e7f80, signalOffset=12, local_signal_index=10, argv=0x7fffffff5cc0) at kernel/qobject.cpp:3713
#56 0x00000000006a473d in FilterController::qt_static_metacall (_o=0x60d00003fb20, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x7fffffff5cc0) at moc_filtercontroller.cpp:128
#55 0x00000000004bb158 in FilterController::setProducer (this=0x60d00003fb20, producer=0x604000d96c90) at controllers/filtercontroller.cpp:117
#54 0x00000000005b7070 in MetadataModel::setIsClipProducer (this=0x60d00003fb48, isClipProducer=true) at models/metadatamodel.cpp:154
#53 0x00007ffff47449fd in QAbstractItemModel::endResetModel (this=0x60d00003fb48) at itemmodels/qabstractitemmodel.cpp:3140
#52 0x00007ffff488ec6f in QAbstractItemModel::modelReset (this=0x60d00003fb48) at .moc/moc_qabstractitemmodel.cpp:637
 [ model reset leads up to clearing, constructing and redrawing the whole filter view ]
#38 0x00007ffff5eff756 in QQuickItemView::modelUpdated (this=0x603001595ef0, changeSet=..., reset=true) at items/qquickitemview.cpp:1228
#37 0x00007ffff5f0245d in QQuickItemViewPrivate::regenerate (this=0x61d00035b680, orientationChanged=false) at items/qquickitemview.cpp:1800
#36 0x00007ffff5f01fd6 in QQuickItemViewPrivate::refill (this=0x61d00035b680) at items/qquickitemview.cpp:1735
#35 0x00007ffff5f02146 in QQuickItemViewPrivate::refill (this=0x61d00035b680, from=-0, to=155) at items/qquickitemview.cpp:1754
#34 0x00007ffff5e9fe8e in QQuickListViewPrivate::addVisibleItems (this=0x61d00035b680, fillFrom=-0, fillTo=155, bufferFrom=-320, bufferTo=475, doBuffer=false) at items/qquicklistview.cpp:658

So for every modification, TimelineDock::clearSelectionIfInvalid is called which calls TimelineDock::setSelection. setSelection previously had an early return for when the selection is the same as before, but this guard was removed in cbc0ddd6.

Then there's how the selected signal will always call FilterController::setProducer, which calls MetadataModel::setIsClipProducer, which resets the entire metadatamodel, leading to lots of work for the view classes.

I think the linux platform implementation for mouse event handling stacks up the mouse events while the windows/os X don't (I've seen similar issues on other qt based projects), explaining why you couldn't see it on non-linux platforms.

[riless]

I have the same Issue on Debian.

If it can help for debbuging, extending a clip in the timeline becomes a little bit faster when I disable snapping.

[Efenstor]

Still not fixed in 160901. Or may be fixed but obviously incompletely. Now if I drag the right edge of a clip it's being dragged reasonably quickly but always quickly gets out of sync with the real cursor position. Which is not much better than freezing.

[metellius]

@ddennedy I tried two fixes here; both fix the problem by breaking the problemsome call chain, but at different places.

One is to just keep TimelineDock::clearSelectionIfInvalid from calling setSelection at all when not needed:

diff --git a/src/docks/timelinedock.cpp b/src/docks/timelinedock.cpp
index 63d1ffc..3990634 100644
--- a/src/docks/timelinedock.cpp
+++ b/src/docks/timelinedock.cpp
@@ -369,6 +369,8 @@ void TimelineDock::clearSelectionIfInvalid()

         newSelection << index;
     }
+    if (newSelection == selection())
+        return;
     setSelection(newSelection);
     emit selectionChanged();
 }

But this feels a bit wrong, as it should ideally be up to TimelineDock::setSelection to figure out if changes are needed or not. Like I mentioned earlier, setSelection had a check for this before, and bringing it back, like this:

diff --git a/src/docks/timelinedock.cpp b/src/docks/timelinedock.cpp
index 63d1ffc..989da44 100644
--- a/src/docks/timelinedock.cpp
+++ b/src/docks/timelinedock.cpp
@@ -255,11 +255,12 @@ void TimelineDock::setSelection(QList<int> newSelection, int trackIndex, bool is
         m_selection.selectedTrack = trackIndex;
         m_selection.isMultitrackSelected = isMultitrack;
         emit selectionChanged();
+
+        if (!m_selection.selectedClips.isEmpty())
+            emitSelectedFromSelection();
+        else
+            emit selected(0);
     }
-    if (!m_selection.selectedClips.isEmpty())
-        emitSelectedFromSelection();
-    else
-        emit selected(0);
 }

 QList<int> TimelineDock::selection() const

...also fixes it, but then (if I read the https://github.com/mltframework/shotcut/commit/cbc0ddd6943ea074ee127fb9774faa9fc678fae3 history right) it might affect a crash with properties changed on the last clip. I wasn't able to reproduce the crash after my fix, but I don't have exact reproduction steps... How should I proceed?

[ddennedy]

Thanks @metellius I tested that your second suggestion improved things and did not introduce a regression.

[tercerapersona]

great news :+1:

[Efenstor]

The issue needs to be reopened because the workaround posted by Metellius seems to be very far from perfect. Here is the video of how it works on my machine (Debian Stretch/AMD64/Radeon R7): https://vid.me/8nSW

[metellius]

I think what you're seeing is an unrelated issue that was not visible previously due to the slowness.

[ddennedy]

@Efenstor The issue as reported is indeed repaired. Your video just seems to be showing that timeline trimming, in general, is still not great behavior. No need to open a bug for that as I do not generally accept improvement requests as bugs. This tracker is for harder defects. Yes, we will try to improve its behavior over time.

[Efenstor]

It's fine. It's quite enough to know that the problem is acknowledged. :)