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

Started by fkuebler, May 04, 2015, 06:06:24 PM

Previous topic - Next topic

fkuebler

Quote from: mean on May 05, 2015, 10:51:35 AM
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
[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

Quote from: Jan Gruuthuse on May 05, 2015, 02:41:58 PM
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


mean

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

fkuebler

Quote from: mean on May 06, 2015, 07:40:13 AM
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



Jan Gruuthuse