Regression: mkv encoder DTS discontinuity

[MB]

Summary of the bug:
How to reproduce:

Download sample from here:
​https://www.datafilehost.com/d/v5QV9Y2BBg

Input file has no errors. Frames are every 40ms (25fps).
DTS progression is linear: 0 - 40 - 80 - 120 - 160 - 200 - 240 - ...

Run this command line:

ffmpeg -i test.mp4 -c copy test.mkv

Output file has DTS discontinuities at 0, 141 and 160ms.
DTS progression is: 0 - 61 - 101 - 141 - 160 - 221 - ...

DTS timings are in milliseconds.

My test configuration was Windows 7 64 bit.
I'm using Zeranoe build of 2016-08-17 (bba6a03).

Zeranoe build of 2015-02-03 has no issues.

Thanks,
MB

[Carl Eugen Hoyos]

Please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket and please explain how the reproduce the "dts discontinuities".

[MB]

Step by step instructions to reproduce DTS errors:

1. Download attached sample (test.mp4);
2. Run ffmpeg -i test.mp4 -c copy test.mkv;
3. Output:

   ffmpeg version N-81378-gbba6a03 Copyright (c) 2000-2016 the FFmpeg developers
     built with gcc 5.4.0 (GCC)
     configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --disable-w32threads --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-libebur128 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
     libavutil      55. 28.100 / 55. 28.100
     libavcodec     57. 53.100 / 57. 53.100
     libavformat    57. 47.101 / 57. 47.101
     libavdevice    57.  0.102 / 57.  0.102
     libavfilter     6. 52.100 /  6. 52.100
     libswscale      4.  1.100 /  4.  1.100
     libswresample   2.  1.100 /  2.  1.100
     libpostproc    54.  0.100 / 54.  0.100
   Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       encoder         : Lavf57.47.101
     Duration: 00:00:10.02, start: 0.000000, bitrate: 1287 kb/s
       Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 1201 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
       Metadata:
         handler_name    : VideoHandler
       Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 81 kb/s (default)
       Metadata:
         handler_name    : SoundHandler
   [matroska @ 023fba20] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead.
       Last message repeated 1 times
   Output #0, matroska, to 'test.mkv':
     Metadata:
       major_brand     : isom
       minor_version   : 512
       compatible_brands: isomiso2avc1mp41
       encoder         : Lavf57.47.101
       Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 1201 kb/s, 25 fps, 25 tbr, 1k tbn, 12800 tbc (default)
       Metadata:
         handler_name    : VideoHandler
       Stream #0:1(und): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 48000 Hz, stereo, 81 kb/s (default)
       Metadata:
         handler_name    : SoundHandler
   Stream mapping:
     Stream #0:0 -> #0:0 (copy)
     Stream #0:1 -> #0:1 (copy)
   Press [q] to stop, [?] for help
   frame=  250 fps=0.0 q=-1.0 Lsize=    1572kB time=00:00:10.00 bitrate=1287.0kbits/s speed= 592x    
   video:1466kB audio:100kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.370809%
   
   

4. Since video track has been copied (-c copy) PTS, DTS and all timecodes of video track must be the same (timebase apart);
5. But...this is not what I've found;
6. Run ffprobe -show_frames test.mkv > mkv.txt and ffprobe -show_frames test.mp4 > mp4.txt;
7. Open the .txt files previously generated;
8. Extract pkt_dts_time fields of video track;
9. For mp4.txt you'll find (diffs in ms on side):

   pkt_dts_time=0.000000
   pkt_dts_time=0.040000   40
   pkt_dts_time=0.080000   40
   pkt_dts_time=0.120000   40
   pkt_dts_time=0.160000   40
   pkt_dts_time=0.200000   40
   ...
   

10. For mkv.txt you'll find (diffs in ms on side):

    pkt_dts_time=0.000000   
    pkt_dts_time=0.061000   61
    pkt_dts_time=0.101000   40
    pkt_dts_time=0.141000   40
    pkt_dts_time=0.160000   19
    pkt_dts_time=0.221000   61
    ...
    

As you can see, DTS in .mkv is not regular like in .mp4. With old ffmpeg builds (2015-02-03 i.e.), it was.

Thanks,
MB

[Carl Eugen Hoyos]

Behaviour has changed several times:
Before 9d4fdfe24c731d1880797dee65365154b41c1dea (related to #4487): 0.080000, 0.120000, 0.160000, 0.200000, 0.240000
Before 65efcaeb8467f5aff25eaf02b20dae43d5ca9dc7 (related to #2324, #2325): 0.021000, 0.061000, 0.101000, 0.141000, 0.181000

[Sasi Inguva]

This file has the same behavior even before the edit list patch ​http://git.videolan.org/?p=ffmpeg.git;a=commit;h=ca6cae73db207f17a0d5507609de12842d8f0ca3 . Something wrong in matroska muxer.

[mkver]

This is a duplicate of #4536: The video is 25p and uses two reordering frames; an edit list makes sure that the pts of the first video sample is zero while its dts is -80ms. The audio meanwhile has an edit list that shows that indicates that the first aac frame is encoder delay, i.e. the actual first frame (that should not be output) has pts=dts=-1024/48000=-21.3333...ms. Given that negative pts in Matroska aren't allowed, ffmpeg shifts them, but the code for shifting is in write_frame and the smaller the dts the earlier the packets get to this function. The first two packets that are fed to write_frame are the first two video frames in coding order -- they have pts of 0 and 160ms respectively which doesn't require shifting because they are already positive. But the next packet according to dts is the first audio packet which has a negative pts and therefore everything is shifted by to make it non-negative. And "everything" only means everything that comes next, the first two frames (in coding order) aren't affected, because they have already been dealt with. So frame 0 and 4 have not been shifted and so the durations of frames 0 (21ms too long), 3 (21ms too short) and 4 (21ms too long) are not what they ought to be.

[mkver]

Fixed in c24ee7c275b6374b4b6ef4030e93d416a9c2265f.

[Balling]

And the mkv file is no longer VFR! Nice.