copyts fails badly for negative start time

[Carl Eugen Hoyos]

​http://ffmpeg.org/pipermail/ffmpeg-user/2017-March/035579.html
A user provided an mpegts sample with negative start time that produces bad output file if audio is copied and video transcoded.

$ ffmpeg -copyts -i 63a2061a-e871-438b-baf3-a05a1ff7a7aa_000000977_cut.ts -acodec copy -qscale 2 -mbd 2 out.ts
ffmpeg version N-84292-gb7cc4eb Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      55. 50.100 / 55. 50.100
  libavcodec     57. 83.100 / 57. 83.100
  libavformat    57. 66.104 / 57. 66.104
  libavdevice    57.  3.100 / 57.  3.100
  libavfilter     6. 77.100 /  6. 77.100
  libswscale      4.  3.101 /  4.  3.101
  libswresample   2.  4.100 /  2.  4.100
  libpostproc    54.  2.100 / 54.  2.100
Input #0, mpegts, from '63a2061a-e871-438b-baf3-a05a1ff7a7aa_000000977_cut.ts':
  Duration: 00:00:04.20, start: -58.427689, bitrate: 4871 kb/s
  Program 1
    Stream #0:0[0x1e4]: Data: timed_id3 (ID3  / 0x20334449)
    Stream #0:1[0x1e1]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:2[0x1e2]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 117 kb/s
Please use -q:a or -q:v, -qscale is ambiguous
Stream mapping:
  Stream #0:1 -> #0:0 (h264 (native) -> mpeg2video (native))
  Stream #0:2 -> #0:1 (copy)
Press [q] to stop, [?] for help
Output #0, mpegts, to 'out.ts':
  Metadata:
    encoder         : Lavf57.66.104
    Stream #0:0: Video: mpeg2video (Main), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc
    Metadata:
      encoder         : Lavc57.83.100 mpeg2video
    Side data:
      cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
    Stream #0:1: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 117 kb/s
[h264 @ 0x34474e0] error while decoding MB 57 20, bytestream -17
[h264 @ 0x34474e0] concealing 1992 DC, 1992 AC, 1992 MV errors in P frame
frame=    0 fps=0.0 q=0.0 Lsize=      73kB time=00:00:00.00 bitrate=N/A dup=0 drop=122 speed=   0x
video:0kB audio:65kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 11.009791%

Output should have 122 video frames.
A similar sample with non-negative start time works fine, the command line without -copyts also works fine.

[Ladislav]

Its not only for negative start time... If you use -copyts - this happens because of a timestamp overflow in the MPEGTS(section 3.3) demuxer. Since timestamps in MPEG-TS have 33 bits and 16 a frequency of 90 kHz, they overflow exactly after 233
90000 95443:72 s
26:51 h.

after 26h 51 min. ffmpeg going down... please fix it beacause it is necessary to use -copyts for preserving audio video sync by transcoding udp multiast streams for example... if you not use this parameter you can expect bad sync in audio video - small problem in audio track is enough... ffmpeg is then not able to hold sync... in cas of clean input stream, everything is ok and you can nto use this...

[Carl Eugen Hoyos]

Replying to ferrys:

it is necessary to use -copyts for preserving audio video sync by transcoding udp multiast streams for example... if you not use this parameter you can expect bad sync in audio video - small problem in audio track is enough... ffmpeg is then not able to hold sync... in case of clean input stream, everything is ok and you can not use this... :)

Please post all usage questions - with command line and complete, uncut console output - on the user mailing list.

[Ladislav]

this problem was fixed by patch here ​https://trac.ffmpeg.org/ticket/5136
but it will be good to repair it in FFMPEG....