crash seeking for deleted keyframe

[ajschult]

With 2.6.0 release or SVN rev 8287, I get a crash if a seek for a deleted key frame.  This seems to happen with various files in various formats.

1. load a file
2. seek to a keyframe in the file
3. select some short range around the keyframe
4. delete the selected range
5. go just after the range
6. seek for the previous keyframe (down arrow)
7. assert failed :flags & AVI_KEY_FRAME at line 452, file ... ADM_segment.cpp

Code Select Expand


/lib64/libADM_core6.so(ADM_backTrack+0x5c) [0x33e82060dc]:0:<ADM_backTrack>:-2
avidemux3_qt4(_ZN17ADM_EditorSegment16intraTimeToFrameEjm+0x46) [0x44dfe6]:1:<ADM_EditorSegment::intraTimeToFrame(unsigned int, unsigned long)>:0
avidemux3_qt4(_ZN12ADM_Composer24GoToIntraTime_noDecodingEmPj+0x87) [0x44a837]:2:<ADM_Composer::GoToIntraTime_noDecoding(unsigned long, unsigned int*)>:0
avidemux3_qt4(_ZN12ADM_Composer18goToIntraTimeVideoEm+0x20) [0x44a9a0]:3:<ADM_Composer::goToIntraTimeVideo(unsigned long)>:0
avidemux3_qt4(_ZN10admPreview14seekToIntraPtsEm+0x17) [0x434d67]:4:<admPreview::seekToIntraPts(unsigned long)>:0
avidemux3_qt4(_ZN10admPreview16previousKeyFrameEv+0x94) [0x434fe4]:5:<admPreview::previousKeyFrame()>:0
avidemux3_qt4(_Z20GUI_PreviousKeyFramev+0x1c) [0x43717c]:6:<GUI_PreviousKeyFrame()>:0
avidemux3_qt4(_Z21HandleAction_Navigate6Action+0x255) [0x4376d5]:7:<HandleAction_Navigate(Action)>:0
avidemux3_qt4(_Z12HandleAction6Action+0x637) [0x4362f7]:8:<HandleAction(Action)>:0
avidemux3_qt4(_ZN10MainWindow10searchMenuEP7QActionP9MenuEntryi+0x40) [0x45d760]:9:<MainWindow::searchMenu(QAction*, MenuEntry*, int)>:0
/lib64/libQtCore.so.4(_ZN11QMetaObject8activateEP7QObjectPKS_iPPv+0x2bf) [0x34e978e71f]:10:<QMetaObject::activate(QObject*, QMetaObject const*, int, void**)>:0
/lib64/libQtGui.so.4(_ZN5QMenu9triggeredEP7QAction+0x32) [0x34eeffd3d2]:11:<QMenu::triggered(QAction*)>:0
/lib64/libQtGui.so.4() [0x34eeffe95b]:12:</lib64/libQtGui.so.4() [0x34eeffe95b]>:0
/lib64/libQtCore.so.4(_ZN11QMetaObject8activateEP7QObjectPKS_iPPv+0x2bf) [0x34e978e71f]:13:<QMetaObject::activate(QObject*, QMetaObject const*, int, void**)>:0
/lib64/libQtGui.so.4(_ZN7QAction9triggeredEb+0x32) [0x34eebc42f2]:14:<QAction::triggered(bool)>:0
/lib64/libQtGui.so.4(_ZN7QAction8activateENS_11ActionEventE+0x70) [0x34eebc44e0]:15:<QAction::activate(QAction::ActionEvent)>:0
/lib64/libQtGui.so.4(_ZN7QAction5eventEP6QEvent+0xa7) [0x34eebc4647]:16:<QAction::event(QEvent*)>:0
/lib64/libQtGui.so.4(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0xac) [0x34eebca4ac]:17:<QApplicationPrivate::notify_helper(QObject*, QEvent*)>:0
/lib64/libQtGui.so.4(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x13a) [0x34eebce92a]:18:<QApplication::notify(QObject*, QEvent*)>:0
/lib64/libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x8e) [0x34e9777f6e]:19:<QCoreApplication::notifyInternal(QObject*, QEvent*)>:0


console output includes

Code Select Expand


[HandleAction]  ************ NextKFrame **************
  [nextKeyFrame]  Current PTS :0 ms
  [searchNextKeyFrameInRef]  Found nextkeyframe 2961 0:0:2 at frame 71
  [nextKeyFrame]  next kf PTS :2961 ms
...
  [removeChunk]  Cutting from 2961 to 3003 ms
...
  [HandleAction]  ************ PreviousKFrame **************
  [previousKeyFrame]  Current PTS :3003 ms
  [previousKeyFrame]  next kf PTS :2961 ms


[Jan Gruuthuse]

My guess/experience would be: you shouldn't select frames around key frame and then cut/delete these. 2.6 is not frame based. Plenty of virtual frames between key frames, these rely on previous and following frames to rebuild picture content. Hence the problem you encounter. With 2.6 you can only make cuts on key frames selected with up or down keyboard arrow.
2.5.6 could be of some help, but not all HD formats are there supported. Should work on SD mpeg-ts and not on HD mpeg-ts.
If you want frame editing you probably have to go to a none compressed video format (re-encode). Do editing and go from there to the wanted format (re-encode again).
2.6 gives you the advantage to cut avc/h.264 video in container or move these from one to another container without re-encoding: main disadvantage you can only cut on these key frames at beginning or in middle of video clip. When at the end, you could cut where you want. If you don't want to append anything else at a later stage.

[mean]

All formats or only some ?
I tried with avi and it seemed ok

[ajschult]

I see this crash with an H264 encoded .mp4 and .flv, an FLV1 encoded .flv and an mpg (DX50) encoded .avi

http://rheneas.eng.buffalo.edu/~andrew/fatkid.flv
(ripped from http://www.youtube.com/watch?v=gqynT-deDuo&feature=fvwrel)
exhibits the problem

[ajschult]

A bit more debugging...

getPKFramePTS gets called with frameTime being some time after the deleted key frame.

getPKFramePTS begins with segment 1 (the second segment, after the deleted range)  and calls searchPreviousKeyFrameInRef with refTime=delta being the original time of the current position.  searchPreviousKeyFrameInRef returns the deleted key frame.

getPKFramePTS recognizes that the frame it got back is not part of segment 1 and rewinds to segment 0.

It now tries to calculate delta and seems to fail.  it takes

delta = *frameTime -  s->_startTimeUs + s->_refStartTimeUs

frameTime is the current time and _startTimeUs=_refStartTimeUs=0, so
delta = *frameTime = refTime

however, *frameTime is bogus as an original time and (in this case) is greater than the original time of the deleted key frame.  searchPreviousKeyFrameInRef will return the deleted key frame (again), but getPKFramePTS will not recognize the problem this time and returns the bogus frame time.

It seems that once it goes back a segment, getPKFramePTS ought to take refTime to be the end of the new (earlier) segment, rather some corrected representation of the current time.

I've actually also seen a crash sometimes in going to the next frame (trying to skip over the deleted key frame) but less consistently... I'll try to see what's happening there as well.

[mean]

Probably fixed by commit r8288

[lenildosb]

friend mean, please, I would like the copy and paste function work again in version 2.6, I use a lot .....

[mean]

Noted, i'll try to have a look next weekend

[ajschult]

Probably fixed by commit r8288

yes, the seek previous keyframe is fixed.  And I also noticed that http://avidemux.org/smuf/index.php/topic,9600.html got fixed. 

I still hit a crash when I seek the next keyframe if I do not delete any frames before the keyframe; if I

1. delete the keyframe and maybe some of the following frames
2. seek back to a earlier position (no longer crashes)
3. seek next keyframe => crash

[ajschult]

right, so getNKFramePTS checks

if(r==false || nkTime > (s->_refStartTimeUs+s->_durationUs))

here, refStartTimeUS=0 and nkTime=_durationUs=998000, so the check fails.  not sure, but perhaps just >=