Hello
In the past I talked about this problem but I never go deep to specify details, now I will do it.
Avidemux 2.6.8 breaks always at specific timestamps on a specific sort of MP4 container.
This personal test was realized by me under windows 8.1 x64, 8 x64, and Seven x86, using both x86 and x64 official 2.6.8v2 versions, and almost all x86 and x64 nightly builds (included the earlier x64 built in January 25),
all the tested versions breaks on the timestamp of this sort of video.
Before continue, I will notice that I also tested Avidemux 2.6.1 x86 downloaded from here: http://sourceforge.net/projects/avidemux-mswin/ (http://sourceforge.net/projects/avidemux-mswin/), and that is the only fine version I found where this bug does not appears. anyways I didn't tested from 2.6.2 to 2.6.7, but just 2.6.1 works ok with this videos.
OK, so lets go.
and this is the crash script:
#PY <- Needed to identify #
#--automatically built--
adm = Avidemux()
adm.loadVideo("C:/Users/Administrador/Desktop/avidemux breaks in second 06.mp4")
adm.clearSegments()
adm.addSegment(0, 0, 14516000)
adm.markerA = 0
adm.markerB = 14516000
adm.videoCodec("Copy")
adm.audioClearTracks()
adm.setSourceTrackLanguage(0,"unknown")
adm.audioAddTrack(0)
adm.audioCodec(0, "copy");
adm.audioSetDrc(0, 0)
adm.audioSetShift(0, 0,0)
adm.setContainer("AVI", "odmlType=1")
Confirmed
Thanks for support, mean.
And sorry for the post contents
regards!
Avidemux things that frame 233 and 235 have the same timestamps
So when it tries to seek the 3rd time, it tries to seek to a keyframe at that timestamp
235 should pop up, but since 233 has also the same timestamp , it triggers an asssert as 233 is not a keyframe
So either the file is slightly incorrect with regards to timing (slight stutters ?) or avidemux decodes the timestamps wrong
Quote from: mean on January 28, 2015, 06:39:56 PM
So either the file is slightly incorrect with regards to timing (slight stutters ?) or avidemux decodes the timestamps wrong
Due to my bad English I'm not sure of what means "slight
stutters" (even translated), but I would like to remember that this problem happens with all videos from that site (ALL), not only one, then I wonder that could be avidemux which decodes the timestamps in a wrong way.
Thanks for read!
It is somehow fixed