FWIW: "Innocent" mp4 gets 3-fold length after editing

[fkuebler]

It smells like bad timestamp decoding
A sample would really help

Heureka!

I could produce an mp4 with Handbrake, using the lowest-most quality settings, resulting in a 680 MB file, which still produces the bug:

https://www.dropbox.com/s/ozuo8h0wsaiikri/_Test-Black-Rain-bad-for-Avidemux.mp4?dl=0

You need only to load this file in Avidemux, edit/cut the first 20 seconds, and then save it from Avidemus with output set to mp4v2. The resulting/saved mp4 will have a (MediaInfo-) length of 6 hours, and when played with VLC or such, will not show video for the first hour or so.

[Jan Gruuthuse]

when cutting @ 0:00:19.019, and save the movie: black screen and indication film has 6 hour duration when playing saved video.

attached terminal output:

[Jan Gruuthuse]

even worse when saving this to mkv

Code Select Expand

[FF] Saving
[saveLoop]  avg fps=24390
  [initUI]  Muxer, creating UI, video duration is 02:04:59,076
  [getPacket]  PTS<DTS : PTS=0 ms , DTS=18446744073709467ms
  [refresh]  XV:refresh
  [adm_lavLogCallback]  [lavc] pts (0) < dts (18446744073709468) in stream 0
[FF]Error writing video packet
[saveLoop]  [FF] Wrote 0 frames, nb audio streams 2
  [saveLoop]  [FF] Found 0 missing PTS / 0 total frames
  [close]  [Mkv] Closing
  [~DIA_encodingQt4]  Destroying encoding qt4
  [~DIA_encodingBase]  DiaEncodingBase: Destroying

terminal output lavcodec to mkv

[Jan Gruuthuse]

weird is when you cut @ next keyframe 0:00:22.897 (3 seconds in between) all is back to normal.

[fkuebler]

weird is when you cut @ next keyframe 0:00:22.897 (3 seconds in between) all is back to normal.

Yes, I can confirm this also for my high quality version. I didn't notice it before.

[Jan Gruuthuse]

Just noticed something else the keyframes selected by avidemu vary in time: 1st, 2nd, 3rd, ... sequential order
0:00:00.083
0:00:02.419
0:00:12.429
0:00:19.019
0:00:22.897
0:00:27.777
0:00.32.365
no idea if this expected or not.

[mean]

thanks for the sample, i'll look into it

[mean]

It is indeed a bad timestamp computation, fixing it...

[fkuebler]

It is indeed a bad timestamp computation, fixing it...

Good to hear... Please let us know, by posting here, when you have uploaded the fix.

[mean]

Should be ready in ~ 30 mn

[fkuebler]

Should be ready in ~ 30 mn

Works perfect. Thank you.

[Jan Gruuthuse]

same here, works fine, thnx