The Overall duration get totally wrong in some containers

[Sami32]

These files are not truncated, at least not showed as it by MediaInfo: darkgraysubs.m2ts.txt MKV-H264-AACHE-2ch (2).mkv.txt Flash.flv.txt

General
Unique ID                                : 179213039155175913603379713516689528352 (0x86D32D04B9CC2541A2050CCC06DD9620)
Complete name                            : F:\!MEDIA_TEST_FILES\UMS Video Testing Suite (20150121)\TESTS\INTERNAL SUBTITLES\MKV-H264-AACHE-2ch (2).mkv
Format                                   : Matroska
Format version                           : Version 4 / Version 2
File size                                : 4.38 MiB
Duration                                 : 13 h 15 min
Overall bit rate                         : 770 b/s
Encoded date                             : UTC 2016-11-27 16:35:52
Writing application                      : mkvmerge v9.5.0 ('Quiet Fire') 32bit
Writing library                          : libebml v1.3.4 + libmatroska v1.4.5

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4
Format settings                          : CABAC / 5 Ref Frames
Format settings, CABAC                   : Yes
Format settings, RefFrames               : 5 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 11 s 428 ms

Note: The general overall bitrate seem incorrect.

[Sami32]

As i don't want open issues if not necessary, i prefer add these durations issues here. They are all using "standard" codecs: DTS, AAC, MPEG-2...

This one is weird with a real 12 s duration reported by the players, perhaps truncation is not detected ? MediaInfo show a duration of 34 mn 56 s LastManStanding.dvr-ms.txt

This one have only the general overall duration, not the audio or video ones: (truncated) Francis en la Marina (1955)_cut.mkv.txt

This one miss the video duration, but have the general and audio ones (truncated file): audio-issue-sample-file.mkv.txt

This one miss only the audio duration (truncated file): j-b-avc-dts-x-ums-sample-file_Truncated.mkv.txt

[mkver]

Regarding MKV-H264-AACHE-2ch (2).mkv: The file is strange: First you have normal video+audio+subtitles for a bit more than 11s; then you sporadically have subtitle packets:

I frame, track 2, timestamp 00:00:11.209000000, size 1033, adler 0x0fb302e1
I frame, track 2, timestamp 00:00:11.209000000, size 1059, adler 0x65090a83
I frame, track 2, timestamp 00:00:11.209000000, size 136, adler 0xafc33cb6
P frame, track 1, timestamp 00:00:11.220000000, size 21052, adler 0x064e01fb
B frame, track 1, timestamp 00:00:11.136000000, size 13482, adler 0x86288c07
B frame, track 1, timestamp 00:00:11.094000000, size 10149, adler 0x8bab9b2b
P frame, track 1, timestamp 00:00:11.178000000, size 12079, adler 0x11ad950c
P frame, track 1, timestamp 00:00:11.386000000, size 18233, adler 0xe0888a39
B frame, track 1, timestamp 00:00:11.303000000, size 14303, adler 0xae25c587
B frame, track 1, timestamp 00:00:11.261000000, size 12441, adler 0x664e4da4
P frame, track 1, timestamp 00:00:11.345000000, size 10733, adler 0x1210dd03
I frame, track 4, timestamp 00:00:12.050000000, size 36, adler 0x03510d34
I frame, track 4, timestamp 00:00:12.315000000, size 71, adler 0xdf211af0
I frame, track 4, timestamp 00:00:13.770000000, size 36, adler 0x0d0d0cde
I frame, track 4, timestamp 00:00:14.035000000, size 71, adler 0xdddd1a5f
I frame, track 4, timestamp 00:00:18.530000000, size 36, adler 0x0dbd0d0c
I frame, track 4, timestamp 00:00:18.795000000, size 71, adler 0xdee41aca
I frame, track 4, timestamp 00:00:21.250000000, size 36, adler 0x0e250d37
I frame, track 4, timestamp 00:00:22.275000000, size 71, adler 0xdda01a39
I frame, track 4, timestamp 00:00:24.930000000, size 36, adler 0x0ed50d65
I frame, track 4, timestamp 00:00:25.195000000, size 71, adler 0xad7119d2
I frame, track 4, timestamp 00:00:28.930000000, size 36, adler 0xfaae0cbe
I frame, track 4, timestamp 00:00:29.195000000, size 71, adler 0xaf291a40
I frame, track 4, timestamp 00:00:30.890000000, size 36, adler 0xfb5e0cec
I frame, track 4, timestamp 00:00:31.155000000, size 71, adler 0xad3419ac
I frame, track 4, timestamp 00:00:32.450000000, size 36, adler 0xf8ca0c18
I frame, track 4, timestamp 00:00:32.715000000, size 71, adler 0xaeec1a1a
I frame, track 4, timestamp 00:00:36.215000000, size 36, adler 0xf97a0c46
I frame, track 5, timestamp 13:15:21.814000000, size 71, adler 0x8f621932
I frame, track 5, timestamp 00:00:09.955000000, size 36, adler 0xef260c54
I frame, track 5, timestamp 00:00:29.955000000, size 71, adler 0x8d6d189e
I frame, track 5, timestamp 00:00:39.955000000, size 36, adler 0xec920b80
I frame, track 5, timestamp 00:00:59.955000000, size 71, adler 0x8f25190c
I frame, track 5, timestamp 00:01:09.955000000, size 36, adler 0xed420bae
I frame, track 5, timestamp 00:01:29.955000000, size 71, adler 0xadb619f5
I frame, track 5, timestamp 00:01:39.955000000, size 36, adler 0xf9fa0c57
I frame, track 5, timestamp 00:01:59.955000000, size 71, adler 0xac721964
I frame, track 5, timestamp 00:02:09.955000000, size 36, adler 0xfaaa0c85
I frame, track 5, timestamp 00:02:29.955000000, size 71, adler 0xad7919cf
I frame, track 5, timestamp 00:02:39.955000000, size 36, adler 0xfb120cb0
I frame, track 5, timestamp 00:02:59.955000000, size 71, adler 0xac35193e
I frame, track 5, timestamp 00:03:09.955000000, size 36, adler 0xfbc20cde
I frame, track 5, timestamp 00:03:29.955000000, size 71, adler 0x7c0618d7
I frame, track 5, timestamp 00:03:39.955000000, size 36, adler 0xe4ae0b38
I frame, track 5, timestamp 00:03:59.955000000, size 71, adler 0x7dbe1945
I frame, track 5, timestamp 00:04:09.955000000, size 36, adler 0xe55e0b66
I frame, track 5, timestamp 00:04:29.955000000, size 71, adler 0x7bc918b1
I frame, track 5, timestamp 00:04:39.955000000, size 36, adler 0xe5c60b91

As you can see track 5 has a packet at 13:15:21.814 which explains why the duration in the header (which MediaInfo seems to rely on) is so big. Btw: 13:15:21 is very close to half the wraparound time for timestamps in a transport stream. This is in all likelihood a result of a bug in mkvmerge.