This looks like this bug that was introduced recently. I get this consistently for many H.264 files with the nightly build 2.6.7 R9010. But if I use the official 2.6.7 build, it does not crash for the same video files. Here is the sequence of steps that generates the crash:
1. mark A at the start of the video
2. drag to a later B position
3. mark B at the end of a segment
4. cut
5. drag to a later position
6. mark A
7. drag to a later position
8. mark B
9. cut
<it crashes at this point, with a seek error>
Here's the backtrace from the log:
[DecodePictureUpToIntra] decode error for frame 1080, not necessarily a problem
[seektoTime] Image not found,searching 36102 ms, got pts=36102 ms
[goToTimeVideo] Cannot seek to beginning of segment 59576576 at 36102 ms
...
*********** BACKTRACE **************
ADM_setCrashHook <+0x99> [C:\Apps\avidemux_2.6.7_r9010\libADM_core6.dll]
ADM_setCrashHook <+0x1F0> [C:\Apps\avidemux_2.6.7_r9010\libADM_core6.dll]
ADM_backTrack <+0xD> [C:\Apps\avidemux_2.6.7_r9010\libADM_core6.dll]
ADM_Composer::samePicture(ADMImage*) <+0x7A> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
admPreview::samePicture() <+0x1B> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
GUI_GoToTime(unsigned long long) <+0x58> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
HandleAction(Action) <+0x73A> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
MainWindow::searchEditMenu(QAction*) <+0x69> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
QMetaObject::activate(QObject*, QMetaObject const*, int, void**) <+0x281> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
QMenu::triggered(QAction*) <+0x34> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QMenu::initStyleOption(QStyleOptionMenuItem*, QAction const*) const <+0x478> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QMetaObject::activate(QObject*, QMetaObject const*, int, void**) <+0x281> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
QAction::triggered(bool) <+0x33> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QAction::activate(QAction::ActionEvent) <+0x6B> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QAction::event(QEvent*) <+0xCA> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QApplicationPrivate::notify_helper(QObject*, QEvent*) <+0x8F> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QApplication::notify(QObject*, QEvent*) <+0x2A2> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QCoreApplication::notifyInternal(QObject*, QEvent*) <+0x70> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
QShortcut::id() const <+0x2081> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QShortcut::id() const <+0x21B5> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QApplication::notify(QObject*, QEvent*) <+0x10E5> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QCoreApplication::notifyInternal(QObject*, QEvent*) <+0x70> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
qt_translateKeyCode(int) <+0x10B4> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
qt_translateKeyCode(int) <+0x2456> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QApplicationPrivate::closePopup(QWidget*) <+0x27DD> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
TranslateMessageEx <+0x2A1> [C:\Windows\system32\USER32.dll]
TranslateMessage <+0x1EA> [C:\Windows\system32\USER32.dll]
QEventDispatcherWin32::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) <+0x67F> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
QApplication::restoreOverrideCursor() <+0x194> [C:\Apps\avidemux_2.6.7_r9010\QtGui4.dll]
QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) <+0x36> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) <+0xEB> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
QCoreApplication::exec() <+0x97> [C:\Apps\avidemux_2.6.7_r9010\QtCore4.dll]
UI_RunApp() <+0x404> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
startAvidemux(int, char**) <+0x429> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
main <+0x54> [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
unknown function [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
unknown function [C:\Apps\avidemux_2.6.7_r9010\avidemux.exe]
BaseThreadInitThunk <+0xD> [C:\Windows\system32\kernel32.dll]
RtlUserThreadStart <+0x21> [C:\Windows\SYSTEM32\ntdll.dll]
*********** BACKTRACE **************
I get the same crash response.
If I select the 2nd I frame from the beginning then everything works.
Did notice that the first I frame was not on time 0.00.
So by pure speculation - maybe after that first edit/cut there are some orphaned B frames left at the start, causing the seek error for the next cut/edit.
Could you provide a very small sample with the timestamps you are using ?
Just tried, it does not happen on my samples
Small sample of AVC in MP4 that gives this seek error on the next edit/cut after chopping of the start.
Using avidemux_r9010_win32 on windows7 ultimate.
Sample link: http://www.datafilehost.com/d/dda159c6
Works here
Could you detail what you are doing ?
I followed the sequence of the OP:
Set Marker A at the beginning of the video (time 00:00:00.083)
Set Marker B a bit down stream
Cut section between A and B
Result: all good so far.
Try another section cut (A + B + cut!)
Result: info dialog pops up with error seeking to xxxx ms
I tried the same sequence on an earlier nightly - r8971_win32 - without getting the seek error.
Instead, when I use the 'seek to start button' this version of the program crashes.
Not so with r9010_win32, it happily returns the slider bar back to the beginning of the video (well almost!).
If I do the first cut from any other frame/type but the start frame then no problem.
Maybe fixed
I'll try it out tonight.
Being curious:
Since the start time for the first frame changes (a bit later!), is something lost in referencing the new first frame?
Thanks mean.
This tiny bug seems fixed.
No seek error or crash on the edit/cut sequence or seek to start frame.
I note that the original time of the first frame is now retained when cutting a section that includes that first frame.
So was this seek error due to referencing the 1st frame with a mismatched start time?
yes