From: Mikko R. <mik...@ik...> - 2010-06-20 16:14:51
|
I'm trying to use latest svn/git on Debian unstable and I've noticed a few problems. I'm not able to pinpoint when exactly this happens, but here's some feed back anyway: * fine tuning clips on timeline and playing moved following clips tens of seconds forward on one video track, corrupting the timeline if project is saved -- workaround is to restart kdenlive with backup project file * playing/previewing project from the start possibly only once, after second try Project Monitor is stuck, no more previews -- workaround is to not play from the beginning but move a few frames forward before playback * some clips continue to play on preview after end points, not always possible to move or delete clips from timeline without restarting kdenlive, and then some timeline corruption has often occurred * File rendering profiles for h264 have bad audio quality even if video quality is high, lots of audible compression artifacts * h264 two pass rendering often stalls at 99%, output file is trash Maybe I should stick to the released version but there I think I had some other problems. -Mikko |
From: Dan D. <da...@de...> - 2010-06-20 17:35:05
|
On Sun, Jun 20, 2010 at 9:14 AM, Mikko Rapeli <mik...@ik...> wrote: > I'm trying to use latest svn/git on Debian unstable and I've noticed a few And svn/git heads of ffmpeg and mlt? > problems. I'm not able to pinpoint when exactly this happens, but here's > some feed back anyway: > > * fine tuning clips on timeline and playing moved following clips tens of > seconds forward on one video track, corrupting the timeline if project is > saved -- workaround is to restart kdenlive with backup project file > > * playing/previewing project from the start possibly only once, > after second try Project Monitor is stuck, no more previews -- workaround > is to not play from the beginning but move a few frames forward before > playback > > * some clips continue to play on preview after end points, not always possible > to move or delete clips from timeline without restarting kdenlive, and > then some timeline corruption has often occurred The above are some very strange problems. While I have not seen them, I am not saying they do not exist because I am not heavily using kdenlive myself, but they do appear they can be the result of a bad build or installation. Did you fully clean the sources before your latest build? Do you have more than one installation of mlt such that it is building against one and running against another? > * File rendering profiles for h264 have bad audio quality even if video > quality is high, lots of audible compression artifacts See aac encoder in FFmpeg. It has been worse that faac, which has reputation for not being great. It continues to improve. > * h264 two pass rendering often stalls at 99%, output file is trash This should be fixed now in MLT git, which I am releasing today. > Maybe I should stick to the released version but there I think I had some > other problems. > -- +-DRD-+ |
From: Mikko R. <mik...@ik...> - 2010-06-20 18:44:54
|
On Sun, Jun 20, 2010 at 10:34:58AM -0700, Dan Dennedy wrote: > On Sun, Jun 20, 2010 at 9:14 AM, Mikko Rapeli <mik...@ik...> wrote: > > I'm trying to use latest svn/git on Debian unstable and I've noticed a few > > And svn/git heads of ffmpeg and mlt? mlt from git, ffmpeg was from debian-multimedia.org. I can try ffmpeg from git too. Maybe I had some build problems so I went back to the packaged one which on dmo seems to be a git snapshot from June 3rd. > > problems. I'm not able to pinpoint when exactly this happens, but here's > > some feed back anyway: > > > > * fine tuning clips on timeline and playing moved following clips tens of > > seconds forward on one video track, corrupting the timeline if project is > > saved -- workaround is to restart kdenlive with backup project file > > > > * playing/previewing project from the start possibly only once, > > after second try Project Monitor is stuck, no more previews -- workaround > > is to not play from the beginning but move a few frames forward before > > playback > > > > * some clips continue to play on preview after end points, not always possible > > to move or delete clips from timeline without restarting kdenlive, and > > then some timeline corruption has often occurred > > The above are some very strange problems. While I have not seen them, > I am not saying they do not exist because I am not heavily using > kdenlive myself, but they do appear they can be the result of a bad > build or installation. Did you fully clean the sources before your > latest build? Do you have more than one installation of mlt such that > it is building against one and running against another? I have seen this kind of things, well, always. On two different machines lately. Worst is the timeline corruption. Especially if timeline in the project is long and not easily checked after each restart. > > * File rendering profiles for h264 have bad audio quality even if video > > quality is high, lots of audible compression artifacts > > See aac encoder in FFmpeg. It has been worse that faac, which has > reputation for not being great. It continues to improve. > > > * h264 two pass rendering often stalls at 99%, output file is trash > > This should be fixed now in MLT git, which I am releasing today. Ok, good to hear. Can't wait to git pull it :) -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-20 19:36:28
|
On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: > * playing/previewing project from the start possibly only once, > after second try Project Monitor is stuck, no more previews -- workaround > is to not play from the beginning but move a few frames forward before > playback ffmpeg, mlt and kdenlive from git and still seeing this. Playing from start the second time locks playback, and trying to play from project tree locks kdenlive. Maybe sdl is to blame? Here what gdb shows: (gdb) info threads 22 Thread 0xa9dbbb70 (LWP 8206) mpegaudio_parse (s1=0xab861e50, avctx=0xad0d5d20, poutbuf=0xa9dbaffc, poutbuf_size=0xa9dbb000, buf=0xab852080 ",Ħ\244{\r#c\r\213\333o0\026\306\344\275\017\022넄ha\371\255_\312ݏ0\201:J\b\232\017\240i\262!/\031\221\031\217\256\245+\337dzo\254\300\016\272K\364h\024\220\025&\207G\031\005lzٕ-`\351i\375\262\365\247\006.\270#\374\324\067\260\f\022\241\354؟ԁWi\261\202\362\225Q\234\017\301\016\236#\362\262\021\235q\217\231bya\323\307\305\355\327g\032Mw٭\300P\350\276%}.\024\343\365_p\207\021\231W\207_\263\261E\226C\261\327\377]\336\365\237@", buf_size=1024) at libavcodec/mpegaudio_parser.c:106 21 Thread 0xaa5dfb70 (LWP 8205) 0xb7fe2424 in __kernel_vsyscall () 15 Thread 0xac6a7b70 (LWP 8199) 0xb7fe2424 in __kernel_vsyscall () 14 Thread 0xacea8b70 (LWP 8198) 0xb7fe2424 in __kernel_vsyscall () 13 Thread 0xb132ab70 (LWP 8197) 0xb7fe2424 in __kernel_vsyscall () * 1 Thread 0xb54d0930 (LWP 8181) 0xb7fe2424 in __kernel_vsyscall () (gdb) bt #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb63f4af5 in pthread_join (threadid=2972887920, thread_return=0x0) at pthread_join.c:89 #2 0xb1bfb808 in consumer_stop (parent=0x88dbf60) at consumer_sdl_preview.c:249 #3 0xb7fbfe64 in mlt_consumer_stop (this=0x88dbf60) at mlt_consumer.c:945 #4 0xb7f982e8 in Mlt::Consumer::stop() () from /usr/lib/libmlt++.so.3 #5 0x080d0b5e in Render::stop (this=0x88db738) at /home/mcfrisk/src/kdenlive-git/src/renderer.cpp:1221 #6 0x0811f6eb in MonitorManager::activateMonitor (this=0x853b7f0, name=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at /home/mcfrisk/src/kdenlive-git/src/monitormanager.cpp:56 #7 0x0811f95e in MonitorManager::slotSwitchMonitors (this=0x853b7f0, activateClip=true) at /home/mcfrisk/src/kdenlive-git/src/monitormanager.cpp:70 #8 0x080c68ee in Monitor::activateMonitor (this=0x88923e0) at /home/mcfrisk/src/kdenlive-git/src/monitor.cpp:493 #9 0x080c7abd in Monitor::slotSetXml (this=0x88923e0, clip=0x8cb39c8, zone=..., position=-1) at /home/mcfrisk/src/kdenlive-git/src/monitor.cpp:722 #10 0x080c7fd4 in Monitor::qt_metacall (this=0x88923e0, _c=QMetaObject::InvokeMetaMethod, _id=47, _a=0xbfffd264) at /home/mcfrisk/src/kdenlive-git/build/src/cmake_bindir/monitor.moc:276 #11 0xb72f780a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**---Type <return> to continue, or q <return> to quit--- ) () from /usr/lib/libQtCore.so.4 #12 0xb73061db in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #13 0x080af54b in ProjectList::clipSelected (this=0x8579028, _t1=0x8cb39c8, _t2=...) at /home/mcfrisk/src/kdenlive-git/build/src/cmake_bindir/projectlist.moc:258 #14 0x080b4249 in ProjectList::slotClipSelected (this=0x8579028) at /home/mcfrisk/src/kdenlive-git/src/projectlist.cpp:517 #15 0x080bed1c in ProjectList::qt_metacall (this=0x8579028, _c=QMetaObject::InvokeMetaMethod, _id=71, _a=0xbfffd44c) at /home/mcfrisk/src/kdenlive-git/build/src/cmake_bindir/projectlist.moc:232 #16 0xb72f780a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #17 0xb73061db in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #18 0xb6e02e77 in QTreeWidget::itemSelectionChanged() () from /usr/lib/libQtGui.so.4 #19 0xb6e05d29 in ?? () from /usr/lib/libQtGui.so.4 #20 0xb6e0f4c8 in QTreeWidget::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libQtGui.so.4 #21 0x0810111f in ProjectListView::qt_metacall (this=0x85bf890, ---Type <return> to continue, or q <return> to quit--- _c=QMetaObject::InvokeMetaMethod, _id=114, _a=0xbfffd644) at /home/mcfrisk/src/kdenlive-git/build/src/cmake_bindir/projectlistview.moc:83 #22 0xb72f780a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4 #23 0xb73061db in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #24 0xb6dde1d9 in QItemSelectionModel::selectionChanged(QItemSelection const&, QItemSelection const&) () from /usr/lib/libQtGui.so.4 #25 0xb6de7523 in QItemSelectionModel::emitSelectionChanged(QItemSelection const&, QItemSelection const&) () from /usr/lib/libQtGui.so.4 #26 0xb6de7833 in QItemSelectionModel::select(QItemSelection const&, QFlags<QItemSelectionModel::SelectionFlag>) () from /usr/lib/libQtGui.so.4 #27 0xb6dc8f7a in ?? () from /usr/lib/libQtGui.so.4 #28 0xb6dc9d7d in QTreeView::setSelection(QRect const&, QFlags<QItemSelectionModel::SelectionFlag>) () from /usr/lib/libQtGui.so.4 #29 0xb6d881cb in QAbstractItemView::mousePressEvent(QMouseEvent*) () from /usr/lib/libQtGui.so.4 #30 0xb6dd28a7 in QTreeView::mousePressEvent(QMouseEvent*) () from /usr/lib/libQtGui.so.4 #31 0xb68427dc in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4 #32 0xb6c3c883 in QFrame::event(QEvent*) () from /usr/lib/libQtGui.so.4 #33 0xb6cd7032 in QAbstractScrollArea::viewportEvent(QEvent*) () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/libQtGui.so.4 #34 0xb6d8c8c7 in QAbstractItemView::viewportEvent(QEvent*) () from /usr/lib/libQtGui.so.4 #35 0xb6dcc12c in QTreeView::viewportEvent(QEvent*) () from /usr/lib/libQtGui.so.4 #36 0xb6cd9a05 in ?? () from /usr/lib/libQtGui.so.4 #37 0xb72f17ca in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #38 0xb67e45a9 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #39 0xb67ebaf7 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #40 0xb7d31b4a in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #41 0xb72f252b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #42 0xb67eaa52 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib/libQtGui.so.4 #43 0xb6875d7c in ?? () from /usr/lib/libQtGui.so.4 #44 0xb687528b in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libQtGui.so.4 #45 0xb68a33e2 in ?? () from /usr/lib/libQtGui.so.4 ---Type <return> to continue, or q <return> to quit--- #46 0xb5e552f5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #47 0xb5e58fd8 in ?? () from /lib/libglib-2.0.so.0 #48 0xb5e591b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #49 0xb731e095 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #50 0xb68a2f45 in ?? () from /usr/lib/libQtGui.so.4 #51 0xb72f0b49 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #52 0xb72f0f9a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #53 0xb72f61cf in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #54 0xb67e4667 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #55 0x08084e1d in main (argc=2, argv=0xbfffef54) at /home/mcfrisk/src/kdenlive-git/src/main.cpp:87 (gdb) thread 13 [Switching to thread 13 (Thread 0xb132ab70 (LWP 8197))]#0 0xb7fe2424 in __kernel_vsyscall () (gdb) bt #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb63f8482 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:179 #2 0xb64e4114 in __pthread_cond_timedwait (cond=0x88ddfc0, mutex=0x88ddfa8, abstime=0xb132a2a0) at forward.c:152 #3 0xb7fc0171 in mlt_consumer_put_frame (this=0x88ddf10, frame=0xad300078) at mlt_consumer.c:456 #4 0xb1bfc0d6 in consumer_thread (arg=0x88dbf60) at consumer_sdl_preview.c:409 #5 0xb63f3955 in start_thread (arg=0xb132ab70) at pthread_create.c:300 #6 0xb64d710e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) thread 14 [Switching to thread 14 (Thread 0xacea8b70 (LWP 8198))]#0 0xb7fe2424 in __kernel_vsyscall () (gdb) bt #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb63f8482 in pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_timedwait.S:179 #2 0xb64e4114 in __pthread_cond_timedwait (cond=0x88ae1a0, mutex=0x88ae188, abstime=0xacea81cc) at forward.c:152 #3 0xb7fc03b9 in mlt_consumer_get_frame (this=0x88ae0f0) at mlt_consumer.c:502 #4 0xb7fc0500 in mlt_consumer_rt_frame (this=0x88ae0f0) at mlt_consumer.c:900 #5 0xb1bfcbf4 in consumer_thread (arg=0x88ae0f0) at consumer_sdl_still.c:560 #6 0xb63f3955 in start_thread (arg=0xacea8b70) at pthread_create.c:300 #7 0xb64d710e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) thread 15 [Switching to thread 15 (Thread 0xac6a7b70 (LWP 8199))]#0 0xb7fe2424 in __kernel_vsyscall () (gdb) bt #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb63f7f7f in __pthread_cond_wait (cond=0x889f498, mutex=0x889f4c8) at pthread_cond_wait.c:153 #2 0xb64e40bd in __pthread_cond_wait (cond=0x889f498, mutex=0x889f4c8) at forward.c:139 #3 0xb1bfc45f in consumer_thread (arg=0x889f380) at consumer_sdl_preview.c:428 #4 0xb63f3955 in start_thread (arg=0xac6a7b70) at pthread_create.c:300 #5 0xb64d710e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) bt #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb63f7f7f in __pthread_cond_wait (cond=0x88ddf78, mutex=0x88ddf60) at pthread_cond_wait.c:153 #2 0xb64e40bd in __pthread_cond_wait (cond=0x88ddf78, mutex=0x88ddf60) at forward.c:139 #3 0xb7fc04b0 in mlt_consumer_rt_frame (this=0x88ddf10) at mlt_consumer.c:892 #4 0xb1bf87ce in consumer_thread (arg=0x88ddf10) at consumer_sdl.c:756 #5 0xb63f3955 in start_thread (arg=0xaa5dfb70) at pthread_create.c:300 #6 0xb64d710e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 |
From: Dan D. <da...@de...> - 2010-06-20 19:50:33
|
On Sun, Jun 20, 2010 at 12:36 PM, Mikko Rapeli <mik...@ik...> wrote: > On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: >> * playing/previewing project from the start possibly only once, >> after second try Project Monitor is stuck, no more previews -- workaround >> is to not play from the beginning but move a few frames forward before >> playback > > ffmpeg, mlt and kdenlive from git and still seeing this. Playing from start > the second time locks playback, and trying to play from project tree > locks kdenlive. Maybe sdl is to blame? Here what gdb shows: I don't know. I can not reproduce it. Find the simplest way to reproduce it and send instructions. For example, does it happen with a color clip? -- +-DRD-+ |
From: Mikko R. <mik...@ik...> - 2010-06-20 20:09:45
|
On Sun, Jun 20, 2010 at 12:50:26PM -0700, Dan Dennedy wrote: > On Sun, Jun 20, 2010 at 12:36 PM, Mikko Rapeli <mik...@ik...> wrote: > > On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: > >> * playing/previewing project from the start possibly only once, > >> after second try Project Monitor is stuck, no more previews -- workaround > >> is to not play from the beginning but move a few frames forward before > >> playback > > > > ffmpeg, mlt and kdenlive from git and still seeing this. Playing from start > > the second time locks playback, and trying to play from project tree > > locks kdenlive. Maybe sdl is to blame? Here what gdb shows: > > I don't know. I can not reproduce it. Find the simplest way to > reproduce it and send instructions. For example, does it happen with a > color clip? Yes, if there's an mp3 sound track. A wav sound track does not trigger this. Reminds of me of last summer when I for some reason ended up using wav's instead of mp3's on the sound track. My machine has latest from Debian unstable. Versions of packages libmlt2 depends on: ii libavcodec52 5:0.6~svn20100620-0mcf02 library to encode decode multimedi ii libavdevice52 5:0.6~svn20100620-0mcf02 ffmpeg device handling library ii libavformat52 5:0.6~svn20100620-0mcf02 ffmpeg file format library ii libavutil50 5:0.6~svn20100620-0mcf02 avutil shared libraries ii libc6 2.11.2-1 Embedded GNU C Library: Shared lib ii libdv4 1.0.0-2 software library for DV format dig ii libgcc1 1:4.4.4-5 GCC support library ii libglib2.0-0 2.24.1-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libjack0 1.9.5~dfsg-13 JACK Audio Connection Kit (librari ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libqt4-svg 4:4.6.3-1 Qt 4 SVG module ii libqt4-xml 4:4.6.3-1 Qt 4 XML module ii libqtcore4 4:4.6.3-1 Qt 4 core module ii libqtgui4 4:4.6.3-1 Qt 4 GUI module ii libquicktime1 3:1.1.5-0.2 library for reading and writing Qu ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra ii libsdl1.2debian 1.2.14-6 Simple DirectMedia Layer ii libsox1b 14.3.1-1 SoX library of audio effects and p ii libstdc++6 4.4.4-5 The GNU Standard C++ Library v3 ii libswscale0 5:0.6~svn20100620-0mcf02 ffmpeg video scaling library ii libvorbisfile3 1.3.1-1 The Vorbis General Audio Compressi ii libx11-6 2:1.3.3-3 X11 client-side library ii libxml2 2.7.7.dfsg-2 GNOME XML library -Mikko |
From: Dan D. <da...@de...> - 2010-06-20 20:50:32
|
On Sun, Jun 20, 2010 at 1:09 PM, Mikko Rapeli <mik...@ik...> wrote: > On Sun, Jun 20, 2010 at 12:50:26PM -0700, Dan Dennedy wrote: >> On Sun, Jun 20, 2010 at 12:36 PM, Mikko Rapeli <mik...@ik...> wrote: >> > On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: >> >> * playing/previewing project from the start possibly only once, >> >> after second try Project Monitor is stuck, no more previews -- workaround >> >> is to not play from the beginning but move a few frames forward before >> >> playback >> > >> > ffmpeg, mlt and kdenlive from git and still seeing this. Playing from start >> > the second time locks playback, and trying to play from project tree >> > locks kdenlive. Maybe sdl is to blame? Here what gdb shows: >> >> I don't know. I can not reproduce it. Find the simplest way to >> reproduce it and send instructions. For example, does it happen with a >> color clip? > > Yes, if there's an mp3 sound track. A wav sound track does not trigger this. These are not instructions; I am losing patience with this discussion. I still can not reproduce it, and I am not going to install Debian and your versions of the packages, so that's meaningless info to me. - start with an empty tree with HD 720p 29.97 fps project settings. - add a black color clip to the tree. - add a mp3 music file to the tree. - put the black clip on track Video 1 at the beginning. - put the mp3 file on track Audio 1 at the beginning. - click in the timeline to give it focus. - press ctrl-home - press space; it plays for a few seconds until I press space to stop - press ctrl-home - press space, it plays for a few seconds works for me. - click the mp3 in the project tree - click play and let it play a few seconds - click play to stop - press ctrl-home - click play and let it play a few seconds works for me. -- +-DRD-+ |
From: Mikko R. <mik...@ik...> - 2010-06-20 21:12:55
|
On Sun, Jun 20, 2010 at 01:50:25PM -0700, Dan Dennedy wrote: > These are not instructions; I am losing patience with this discussion. > I still can not reproduce it, and I am not going to install Debian and > your versions of the packages, so that's meaningless info to me. The package info was there just for the info, nothing more. Using wav's is a new workaround for me, found through this discussion and I'm grateful for that. For the record I started a new project, used only color clip, added an mp3, move both to the beginning of timeline and the problem shows up. Without audio and with a wav format audio the problem doesn't show up. I remember fighting with this problem while editing a few clips in early May. Was kind of hard to put a title to the beginning. I whish I could reproduce the timeline corruptions with color clips too. Tried but failed sofar. -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-20 19:56:00
|
On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: > * some clips continue to play on preview after end points, not always possible > to move or delete clips from timeline without restarting kdenlive, and > then some timeline corruption has often occurred Just saw this again with latest ffmpeg, mlt and kdenlive. Moved a clip from track one to track three and after a few adjustments to other clips this clips end point is moved according to preview. Timeline shows the clip ending in correct place but playback continues after it. Saving the project and re-opening it shows that the clips end point is 15 seconds off. Maybe at the place where it was before the clip got moved. Can't see anything interesting in the logs or debugger. -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-20 22:06:23
|
On Sun, Jun 20, 2010 at 10:55:35PM +0300, Mikko Rapeli wrote: > On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: > > * some clips continue to play on preview after end points, not always possible > > to move or delete clips from timeline without restarting kdenlive, and > > then some timeline corruption has often occurred > > Just saw this again with latest ffmpeg, mlt and kdenlive. Moved a clip from > track one to track three and after a few adjustments to other clips > this clips end point is moved according to preview. Timeline shows the > clip ending in correct place but playback continues after it. Saving the > project and re-opening it shows that the clips end point is 15 seconds off. > Maybe at the place where it was before the clip got moved. > > Can't see anything interesting in the logs or debugger. I see Till's commits coming in to maybe hunt this down, but until a1f807dd8728ff275af6da7fcfb1ab6f2a84f7cc or 4536 this isn't fixed yet. I'm hitting the problem quite heavily in my current project where I'm moving clips to match the sound track. -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-21 17:22:28
|
On Sun, Jun 20, 2010 at 10:55:35PM +0300, Mikko Rapeli wrote: > On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: > > * some clips continue to play on preview after end points, not always possible > > to move or delete clips from timeline without restarting kdenlive, and > > then some timeline corruption has often occurred > > Just saw this again with latest ffmpeg, mlt and kdenlive. Moved a clip from > track one to track three and after a few adjustments to other clips > this clips end point is moved according to preview. Timeline shows the > clip ending in correct place but playback continues after it. Saving the > project and re-opening it shows that the clips end point is 15 seconds off. > Maybe at the place where it was before the clip got moved. Looks like this is caused by an odd file format created by slowing down a 720p60 clip to 720p30 with ffmpeg: http://mcfrisk.kapsi.fi/linux/video/#index2h2 Here's a sample: http://mcfrisk.kapsi.fi/temp/GOPR0022_slow_motion.mov Created a new project in kdenlive, added that file and created two color clips. Moved all of them to the timeline. Then I played with the files on time line: move them around one by one and in selected groups, from one track to another, shortened them, moved in and out poits around, play the timeline etc and after a few minutes I can see this: http://mcfrisk.kapsi.fi/temp/kdenlive_timeline_problem.png There's propably a lot wrong with the slow motion clip, but I have no idea how to fix it. -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-21 21:06:18
|
On Mon, Jun 21, 2010 at 08:22:04PM +0300, Mikko Rapeli wrote: > On Sun, Jun 20, 2010 at 10:55:35PM +0300, Mikko Rapeli wrote: > > On Sun, Jun 20, 2010 at 07:14:28PM +0300, Mikko Rapeli wrote: > > > * some clips continue to play on preview after end points, not always possible > > > to move or delete clips from timeline without restarting kdenlive, and > > > then some timeline corruption has often occurred > > > > Just saw this again with latest ffmpeg, mlt and kdenlive. Moved a clip from > > track one to track three and after a few adjustments to other clips > > this clips end point is moved according to preview. Timeline shows the > > clip ending in correct place but playback continues after it. Saving the > > project and re-opening it shows that the clips end point is 15 seconds off. > > Maybe at the place where it was before the clip got moved. > > Looks like this is caused by an odd file format created by slowing down a > 720p60 clip to 720p30 with ffmpeg: I got to take this back. Using kdenlive 0.7.7.1 I was able to fix and finish the corrupted project without any problems. I'll try to find out the offending commit with git bisect. -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-22 19:54:04
|
On Tue, Jun 22, 2010 at 12:40:48PM -0700, Dan Dennedy wrote: > The log entry for svn-r4413 is > r4413 | j-b-m | 2010-05-06 02:48:39 -0700 (Thu, 06 May 2010) | 2 lines > > Try to correctly fix issue resize start issue: > http://kdenlive.org/mantis/view.php?id=1575 > > I read that bug, and it is about an issue I was having yesterday while > testing updates on one of my systems. I was testing the improved Pan & > Zoom on a still image and getting strange, disconcerting results. > Then, I learned it was due to how I was editing this still image clip. > After placing it on the timeline somewhere other than the beginning, I > was resizing the duration from its start end. That alone showed the > problem in Pan & Zoom - it was not doing as I instructed, as if filter > in/out points are wrong, which is something jb and I recently fixed > and should be working! If you then move the clip to the left on the > timeline, the project duration is now shorter than it should be > furthering problems. Is this similar to not being able to move a clip on timeline after adjusting other clips start and end points before that clip? I checked again to git master and this problem was the first problem I hit with my project. -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-22 19:17:33
|
On Tue, Jun 22, 2010 at 12:05:55AM +0300, Mikko Rapeli wrote: > I got to take this back. Using kdenlive 0.7.7.1 I was able to fix and finish > the corrupted project without any problems. I'll try to find out the offending > commit with git bisect. First of all, thanks for keeping project files compatible between 0.7.7.1 and latest development tree, and having a git tree available made tracing this a whole lot easier to me. I found a dumb way of reproducing the problem somewhat reliably on my project and after 26 tries this commit is to blame: git 6b51c6a10ab7a7f8e856e83b157f188a04c749d6 svn 4413 Since reproducing was a bit of a black art I did one run with git bisect and one manual walk back a few commits to be sure. That commit is pretty big, so I split it down. The bad piece of code the one below. As a final wish/whine: please commit changes in smaller logical pieces. For example git add -p file_with_ton_of_changes.cpp can help to split patches. diff --git a/src/renderer.cpp b/src/renderer.cpp index ad5793d..247e913 100644 --- a/src/renderer.cpp +++ b/src/renderer.cpp @@ -2750,17 +2750,15 @@ bool Render::mltResizeClipStart(ItemInfo info, GenTime diff) } mlt_service_lock(service.get_service()); int clipIndex = trackPlaylist.get_clip_index_at(info.startPos.frames(m_fps)); - Mlt::Producer *clip = trackPlaylist.get_clip(clipIndex); - if (clip == NULL) { + if (trackPlaylist.is_blank(clipIndex)) { kDebug() << "//////// ERROR RSIZING NULL CLIP!!!!!!!!!!!"; mlt_service_unlock(service.get_service()); return false; } - int previousStart = clip->get_in(); - delete clip; + int previousStart = trackPlaylist.clip_start(clipIndex); int previousDuration = trackPlaylist.clip_length(clipIndex) - 1; m_isBlocked = true; - kDebug() << "RESIZE, old start: " << previousStart << ", PREV DUR: " << previousDuration << ", DIFF: " << moveFrame; + kDebug() << "RESIZE, old start: " << previousStart + moveFrame<<", "<<previousStart + previousDuration; trackPlaylist.resize_clip(clipIndex, previousStart + moveFrame, previousStart + previousDuration); if (moveFrame > 0) trackPlaylist.insert_blank(clipIndex, moveFrame - 1); else { |
From: Mikko R. <mik...@ik...> - 2010-06-22 19:34:32
|
On Tue, Jun 22, 2010 at 10:17:09PM +0300, Mikko Rapeli wrote: > I found a dumb way of reproducing the problem somewhat reliably on my project > and after 26 tries this commit is to blame: > > git 6b51c6a10ab7a7f8e856e83b157f188a04c749d6 > svn 4413 Blah, I see I was tracing the wrong problem. This one was fixed in svn 4524. -Mikko |
From: Mikko R. <mik...@ik...> - 2010-06-22 20:35:37
|
On Tue, Jun 22, 2010 at 10:53:40PM +0300, Mikko Rapeli wrote: > Is this similar to not being able to move a clip on timeline after adjusting > other clips start and end points before that clip? > > I checked again to git master and this problem was the first problem I hit > with my project. Moved start and end positions of two clips on same track prior to a third clip. Third clip can no longer be moved due some error. git bisect and patch splitting points to the patch below. On Tue, Jun 22, 2010 at 10:17:09PM +0300, Mikko Rapeli wrote: > diff --git a/src/renderer.cpp b/src/renderer.cpp > index ad5793d..247e913 100644 > --- a/src/renderer.cpp > +++ b/src/renderer.cpp > @@ -2750,17 +2750,15 @@ bool Render::mltResizeClipStart(ItemInfo info, GenTime diff) > } > mlt_service_lock(service.get_service()); > int clipIndex = trackPlaylist.get_clip_index_at(info.startPos.frames(m_fps)); > - Mlt::Producer *clip = trackPlaylist.get_clip(clipIndex); > - if (clip == NULL) { > + if (trackPlaylist.is_blank(clipIndex)) { > kDebug() << "//////// ERROR RSIZING NULL CLIP!!!!!!!!!!!"; > mlt_service_unlock(service.get_service()); > return false; > } > - int previousStart = clip->get_in(); > - delete clip; > + int previousStart = trackPlaylist.clip_start(clipIndex); > int previousDuration = trackPlaylist.clip_length(clipIndex) - 1; > m_isBlocked = true; > - kDebug() << "RESIZE, old start: " << previousStart << ", PREV DUR: " << previousDuration << ", DIFF: " << moveFrame; > + kDebug() << "RESIZE, old start: " << previousStart + moveFrame<<", "<<previousStart + previousDuration; > trackPlaylist.resize_clip(clipIndex, previousStart + moveFrame, previousStart + previousDuration); > if (moveFrame > 0) trackPlaylist.insert_blank(clipIndex, moveFrame - 1); > else { |
From: jb <jb...@kd...> - 2010-06-22 21:00:00
|
On Tuesday 22 June 2010 21.35:14 Mikko Rapeli wrote: > On Tue, Jun 22, 2010 at 10:53:40PM +0300, Mikko Rapeli wrote: > > Is this similar to not being able to move a clip on timeline after > > adjusting other clips start and end points before that clip? > > > > I checked again to git master and this problem was the first problem I > > hit with my project. > > Moved start and end positions of two clips on same track prior to a third > clip. Third clip can no longer be moved due some error. git bisect and > patch splitting points to the patch below. I just fixed a corruption when resizing image or color clips from the start. Can you please try again with latest svn? I cannot reproduce your problem here. If you still have the problem, can you send a simple project file that shows this issue? regards jb |
From: Mikko R. <mik...@ik...> - 2010-06-22 21:15:02
|
On Tue, Jun 22, 2010 at 09:59:50PM +0100, jb wrote: > I just fixed a corruption when resizing image or color clips from the start. > Can you please try again with latest svn? I cannot reproduce your problem > here. Yes, saw the commit through irc. After moving clip start and end points on the problematic project for ten minutes there's no sign of the problem so it is fixed. Thank you! -Mikko |
From: Dan D. <da...@de...> - 2010-06-22 19:40:56
|
On Tue, Jun 22, 2010 at 12:17 PM, Mikko Rapeli <mik...@ik...> wrote: > On Tue, Jun 22, 2010 at 12:05:55AM +0300, Mikko Rapeli wrote: >> I got to take this back. Using kdenlive 0.7.7.1 I was able to fix and finish >> the corrupted project without any problems. I'll try to find out the offending >> commit with git bisect. > > First of all, thanks for keeping project files compatible between 0.7.7.1 and > latest development tree, and having a git tree available made tracing this > a whole lot easier to me. > > I found a dumb way of reproducing the problem somewhat reliably on my project > and after 26 tries this commit is to blame: > > git 6b51c6a10ab7a7f8e856e83b157f188a04c749d6 > svn 4413 > > Since reproducing was a bit of a black art I did one run with git bisect > and one manual walk back a few commits to be sure. That commit is pretty big, > so I split it down. The bad piece of code the one below. The log entry for svn-r4413 is r4413 | j-b-m | 2010-05-06 02:48:39 -0700 (Thu, 06 May 2010) | 2 lines Try to correctly fix issue resize start issue: http://kdenlive.org/mantis/view.php?id=1575 I read that bug, and it is about an issue I was having yesterday while testing updates on one of my systems. I was testing the improved Pan & Zoom on a still image and getting strange, disconcerting results. Then, I learned it was due to how I was editing this still image clip. After placing it on the timeline somewhere other than the beginning, I was resizing the duration from its start end. That alone showed the problem in Pan & Zoom - it was not doing as I instructed, as if filter in/out points are wrong, which is something jb and I recently fixed and should be working! If you then move the clip to the left on the timeline, the project duration is now shorter than it should be furthering problems. -- +-DRD-+ |