2.6.10 seek error for MP4 files

[tpm9280]

I just tried 2.6.10, and I frequently experience a seek error in editing MP4 files that I do not get in 2.6.7.  The following steps consistently cause the problem. 

version:  2.6.10
OS:  Windows 7

1.  Load an MP4 video. 

If the "Time:" field at the bottom left of the window displays "00:00:00.000" then the error won't occur.  But if it is something like "00:00:00.083" or some other non-zero value, then there will be a seek error later.

2.  Press the following keys in sequence: '[', ']', 'Delete'

The "Time:" field still reads something like "00:00:00.083".

3.  Press the following keys in sequence:  '[', 'Delete'

A window pops up that says something like "Error seekting to 100 ms" (see avidemux-crash-0 attachment).

Another window will appear either immediately upon pressing OK or sometime later (if further editing is attempted) displaying a stack trace.  It indicates a crash in ADM_Composer::samePicture (see avidemux-crash attachment).

I have also attached the admlog.txt that was created upon loading crash.py later.

I realize that this sequence of commands would delete the whole video, but this is just the quickest way to reproduce the problem.  The key steps seem to be an initial edit which does not include the 0 frame and a final edit that includes some remainder of the video all the way to the end.

[AQUAR]

Have a look at this thread as I think it probably relates to the same issue.
It seemed to be fixed but maybe it snuck back in!
http://avidemux.org/smif/index.php/topic,14575.msg68459.html#msg68459

[tpm9280]

Yes, that looks like the same bug.  Also, I've seen this with other video formats as well (not just MP4).

I have a workaround: If the time field is non-zero when loading the video, press "]", "Delete" to delete the first few frames.  I'm assuming that this will strip off leading B frames, so that the first frame is an I frame.

[AQUAR]

It might be a time stamp error on that first I frame!

I too used to presume that a non zero time reference on the first I frame was caused by some orphaned predictive frames in front of it, but I seem to recall the developer mentioning something about latency.

   

[mean]

It's an internal logic erorr in the composer
It's not easy to fix as it is a sort of exception that has to be handled everywhere

[AQUAR]

Thanks for that.