Avidemux 2.8.0 display way off current time as you play it. VLC displays it perfectly. Here are two screenshots and the video causing the issue:
avidemux-vlc (https://mega.nz/folder/hA9QARbR#QCXWoZfls9jqBL9QocsmnQ)
Both are right ;D
The duration shown by Avidemux is calculated from the presentation timestamp (PTS) of the first keyframe to the end of the video, which is usually the PTS of the frame which should be displayed last + frame duration.
The duration shown by VLC is calculated from the absolute starting point of presentation time in the video. They are different because the edit list for the video track in this MP4 file specifies a delay of 5 seconds (5000 ticks in movie scale units which are 1/1000 of a second here = 5 seconds) for this track, i.e. VLC starts counting time from 5 seconds, Avidemux from zero.
The video was cut by ffmpeg, I assume it's a bug introduced by it, because opening the original video both show the same, unlike in this case.
There is no bug in sense that edit lists are the valid way to shift tracks. The info tells the application which demuxes the file to skip the first 5 seconds of audio. FFmpeg kept audio data and shifted video, Avidemux would just drop audio packets at the start of audio stream when they are too early for video.
I've tested different methods for muxing a video with a shorter audio track (delayed audio with no re-encoding).
1) ffmpeg -i "video.mp4" -itsoffset 60 -i "audio.m4a" -c copy -map 0:v -map 1:a delayed_1.mp4
2) mkvtoolnix, delay(ms): 60000 >> delayed_2.mkv
3) Avidemux, delay, audio shift(ms): 60000 >> delayed_3.mp4, delayed_4.mkv
I've tested the output with different video players on windows and android.
Conclusions:
- Avidemux can load the files and applies the delay.
- Not clear what is the best method. Some video players will have trouble playing the output file. Basic mp4 players will ignore the delay. VLC seems to work best.