PTS incorrectly fixed up to be negative

[Dan Sanders]

Sample files available from:

​https://bugs.chromium.org/p/chromium/issues/detail?id=721451
​https://bugs.chromium.org/p/chromium/issues/detail?id=723537

In the three cases reported above (7001A.mp4, MVI_5623.mp4, and nonFormattedMetaData.mp4), the first frame in presentation order is not the first frame in decode order. The metadata correctly records this. However, FFmpeg is reporting that the first frame in decode order is at time 0 (therefore the first frame in presentation order has a negative timestamp).

Example (MVI_5623.mp4):

(edit offset is 40ms)

# PTS PTS (after edit) ffprobe pts_time
- --- ---------------- ----------------
0 120  80                0
1  40   0              -80
2  80  40              -40
3 240 200              120
4 160 120               40
5 200 160               80
6 360 320              240
7 280 240              160

(Tested with ffprobe at b946bd8ef2c7aeee09469a4901182a44f9b67189, 2017-05-25)

For comparison, ffprobe at release 2.8.11 reports the expected values:

# PTS PTS (after edit) ffprobe pts_time
- --- ---------------- ----------------
0 120  80               80
1  40   0                0
...

[Carl Eugen Hoyos]

Replying to sandersd:

For future tickets: Please remember to always provide an as-simple-as-possible ffmpeg command line that allows to reproduce the issue together with the complete, uncut console output, do not report issues against ffprobe if they are reproducible with ffmpeg.

In the three cases reported above (7001A.mp4, MVI_5623.mp4, and nonFormattedMetaData.mp4), the first frame in presentation order is not the first frame in decode order. The metadata correctly records this. However, FFmpeg is reporting that the first frame in decode order is at time 0

(therefore the first frame in presentation order has a negative timestamp).

Why do you think this is an issue?

I only found 7001A.mp4 and nonFormattedMetaData.mp4, where can I get MVI_5623.mp4?

I cannot reproduce negative timestamps with nonFormattedMetaData.mp4, if there is an issue for 7001A.mp4, it is a regression since ca6cae73db207f17a0d5507609de12842d8f0ca3

[Dan Sanders]

I only found 7001A.mp4 and nonFormattedMetaData.mp4, where can I get MVI_5623.mp4?

MVI_5623.mp4 is linked from the initial user report of the first bug,
​https://bugs.chromium.org/p/chromium/issues/detail?id=723537.

Why do you think this is an issue?

The demuxer still reports a track start time of zero. This breaks playback in Chrome, but more importantly it prevents correct A/V sync.

I cannot reproduce negative timestamps with nonFormattedMetaData.mp4

I see that the second PTS is negative with a tip-of-tree build from today:

$ ~/opt/ffmpeg-git/ffprobe -show_packets -select_streams video -i nonFormattedMetaData.mp4 | head -n 30
ffprobe version N-86265-gb946bd8ef2 Copyright (c) 2007-2017 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
  configuration: --enable-gpl --enable-libvpx --enable-libx264
  libavutil      55. 63.100 / 55. 63.100
  libavcodec     57. 96.101 / 57. 96.101
  libavformat    57. 72.101 / 57. 72.101
  libavdevice    57.  7.100 / 57.  7.100
  libavfilter     6. 90.100 /  6. 90.100
  libswscale      4.  7.101 /  4.  7.101
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'nonFormattedMetaData.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp42avc1CAEP
    creation_time   : 2017-05-25T11:52:00.000000Z
  Duration: 00:00:32.03, start: 0.000000, bitrate: 4024 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709), 1280x720, 3852 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 60k tbc (default)
    Metadata:
      creation_time   : 2017-05-25T11:52:00.000000Z
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      creation_time   : 2017-05-25T11:52:00.000000Z
[PACKET]
codec_type=video
stream_index=0
pts=0
pts_time=0.000000
dts=-3003
dts_time=-0.100100
duration=1001
duration_time=0.033367
convergence_duration=N/A
convergence_duration_time=N/A
size=109271
pos=171912
flags=K_
[/PACKET]
[PACKET]
codec_type=video
stream_index=0
pts=-2002
pts_time=-0.066733
dts=-2002
dts_time=-0.066733
duration=1001
duration_time=0.033367
convergence_duration=N/A
convergence_duration_time=N/A
size=12534
pos=281183
flags=__
[/PACKET]

[Dale Curtis]

Any updates here? Thanks in advance!

[Dale Curtis]

Looks like we can set advanced_editlist=0 to resolve this temporarily.

[Sasi Inguva]

This is a bug in the edit list fix index code. This line ​http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=3845e63b5359a135ea322acd28729dbdb2722019;hb=HEAD#l3087 , causes the PTS to be negative. The intention of the line is to make the first pts to be zero. But the problem here is that the first packet in the decoding order is not the first packet in the presentation order, and in that line we are subtracting by the timestamp of the first packet in decoding order. What we need to do is find the first packet in the presentation order and its resulting PTS after edit list is applied, and then offset all the timestamps to make that PTS zero. I am working on that fix.

You can do -advanced_editlist=0 to disable the fix index feature, but keep in mind that without that feature you will have AVSync issues anyway, because the timestamps are not adjusted properly according to the edit list.

[Sasi Inguva]

Also noting that, this is just a problem for videos starting with open-GOP. i.e. videos where the first frame is the B-frame. (Only then will you have the first ctts to be not zero).

[Sasi Inguva]

Sent the patch for review. PTAL.

[Sasi Inguva]

Should be fixed in 93db5e3fc41ac0242acab86c3e4ce3a3dfb80075

[Carl Eugen Hoyos]

The long commit message may or may not help understanding the issue better, for future bug fixes, please remember to always mention the fixed ticket.
Thank you for working on these reports!