timeline does not start at beginning

Started by aeryn.sun, January 05, 2018, 09:52:54 AM

Previous topic - Next topic

aeryn.sun

Hi,

i downloaded and installed the linux 64bit universal binary 2.7.0 to use it on my 64bit xubuntu 17.10. When i load video files (.mkv) previously created with handbrake, the timeline does not start at the beginning. Eg for a 2h 41m 59s video i get the time values 7h 55m 34s (duration) and 5h 12m 35s (beginning). When i try to go to previous keyframe, this is not possible:
Cannot find keyframe with PTS less than 05:12:35,663
See screenshot.

I also tried to cut some time at the beginning with ffmpeg but the result in avidemux is always the same.

Anyone encountered this behavior before / is there a solution for this?

eumagga0x2a

Please try the latest git master (build it yourself, this is trivial on *ubuntu).

sudo apt-get install git
git clone https://github.com/mean00/avidemux2.git
cd avidemux2
bash createDebFromSourceUbuntu.bash


If the problem persists, please provide a sample video.

The topic would better fit into http://avidemux.org/smif/index.php/board,23.0.html (please ignore "2.6" in the header, it is just the main support forum) or http://avidemux.org/smif/index.php/board,20.0.html.

aeryn.sun

hi,

compilation worked fine. same problem occurs. I took the original video file and cut just 2min out of it.
duration:
mpv: 2min
mkvinfo: 120s
avidemux: 3m 54s

i uploaded the file here: https://ufile.io/8zel3 (t.mkv)

thnx

eumagga0x2a

Thank you, the video doesn't provide DTS (decode time stamps) and Avidemux does something wrong in guessing the value.

aeryn.sun

i did some additional testing. with handbrake i created a the same video using same settings but this time a .mp4. The problem with the wrong beginning of the timeline in avidemux disappeared. now when chosing copy as video and audio output i get a  audio delay of 1s. besides mpv is no more able to play the cut file flawlessly even with hardware acceleration enabled, ffplay and mplayer1 work fine  8)

i am going to do some more testing. i am willing to accept the audio delay if the value is always the same.

eumagga0x2a

ffprobe disagrees with Avidemux about missing DTS, but the file is indeed highly problematic because it doesn't have a single frame rate but the duration of frames is either 20 ms (50 fps) or twice as long at 40 ms (25 fps).

ffprobe -show_packets t.mkv | grep dts\= | head -n 20
ffprobe version 3.3.5 Copyright (c) 2007-2017 the FFmpeg developers
[...]
Input #0, matroska,webm, from 't.mkv':
  Metadata:
    ENCODER         : Lavf57.71.100
  Duration: 00:02:00.12, start: 0.000000, bitrate: 1015 kb/s
    Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 960x540 [SAR 1233:1232 DAR 137:77], SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 180k tbc (default)
    Metadata:
      DURATION        : 00:02:00.120000000
    Stream #0:1(cze): Audio: ac3, 48000 Hz, 2 channels, fltp (default)
    Metadata:
      DURATION        : 00:02:00.006000000
dts=N/A
dts=N/A
dts=0
dts=20
dts=40
dts=80
dts=100
dts=120
dts=160
dts=180
dts=200
dts=240
dts=260
dts=280
dts=320
dts=360
dts=400
dts=420
dts=440
dts=480


The same for PTS:

pts=0
pts=100
pts=40
pts=20
pts=80
pts=180
pts=120
pts=160
pts=260
pts=200
pts=240
pts=320
pts=280
pts=440
pts=400
pts=360
pts=420
pts=540
pts=500
pts=480


(PTS are not monotonously increasing because the video contains B-frames, but when reordered, we get frame durations 20, 20, 40, 20, 20, 40, 20, 20, 40, 20, 20, 40 etc.).

Avidemux takes the higher value and due to DTS missing (or missing due to an issue in Avidemux) puts all DTS in 40 ms steps. But with frame duration jumping between two values, DTS start to overtake PTS (presentation time stamps) very quickly. As DTS can never be past PTS (we must decode a frame prior to displaying it), Avidemux delays all PTS to enforce PTS>=DTS. This results in the insanely high first frame PTS you experience here.