NOTE: This question is superceded by this new one, please do not answer below this post.

What happened?

  • [Edit] DVB file ('file1') in TS format of H.264/AC3@50i cannot be properly remuxed into any of the following formats: isom/mp4; QuickTime MOV; Matroska

  • Another DVB file ('file2') in TS format of MPEG-2/MP2@59.94i can be properly remuxed into any of the following formats: MPEG; isom/mp4. QuickTime MOV and Matroska are not tried.

  • [Update] Still another one in TS format of H.264/AAC@29.97p can be properly remuxed into isom/mp4 without a hitch, not requiring any ffmpeg switches other than -i, -c copy.

Technical details

  • FFMpeg reports millions of the following error messages, with or without any possible combination of these switches: -fflags +genpts, -fflags +igndts, -fflags +discardcorrupt

    • Command line is ffmpeg.exe -fflags +igndts -fflags +genpts -fflags +discardcorrupt -i INPUT -c copy -format mp4 OUTPUT
    • Error Message 1:
      [mp4 @ address] pts has no value
      Last message repeated xxx times
    • Error Message 2:
      [mp4 @ address] Non-monotonous DTS in output stream 0:0. Previous ... Current ... Changing to ... , blah blah
  • AVIDemux completes operation with wrong metadata and faulty playback. File properties and playback behaviour resembles that created by FFMpeg

    • Frame-rate becomes variable, should be 50i
    • Average frame-rate is not the correct value, showing very strange numbers
    • Playback frame-rate is abnormal, oscillating btw. 59.94 and 39.xx
  • [Edit] MP4box reports the following warnings for 2 times, and produces jagged picture with wrong frame-rate as mentioned above. If you view the resultant video very carefully you will see the image with many blocks; this is not found in the original file.

    • Command line is mp4box.exe -fps 50 -add "INPUT#video" OUTPUT
    • Error Message:
      [MPEG-2 TS] PID xx PCR discontinuity signaled but diff is small (diff xx us - PCR diff xx vs prev PCR diff 0) - ignore it

My questions, in detail

1 What on earth is "DTS" and "PTS"? They seem to be obsructing a successful remux.
2 Is this due to corrupted file or software bug (see https://trac.ffmpeg.org/ticket/4768 and https://trac.ffmpeg.org/ticket/502)?
3 If this is a software bug what are the work-arounds?
4 Any workable solution that remuxes MPEG Transport Streams to MP4 are welcome. MPEG-TS takes up too much overhead and are not well supported across platforms and systems.

Diagnostic Information
- MediaInfo dump of file1, file2, and file1 remuxed into mp4 by FFMpeg

  • 2
    What does corrupted playback mean - decoding errors? Is the playback speed always wrong or it varies? – Gyan Jan 31 '18 at 16:33
  • @Mulvya, playback speed is always wrong; frame image seems fine; the decoder can work but apparently the file isn't usable. – user786008 Feb 1 '18 at 3:24
  • Does a TS to TS remux preserve playback rate? The store method of file1 is unusual. Try with ffmbc. If you can't compile, get an older binary from videohelp.com/software/ffmbc – Gyan Feb 1 '18 at 5:53
  • @Mulvya , TS→TS remux works in FFMpeg with the following options specified: -mpegts_service_type advanced_codec_digital_hdtv -mpegts_m2ts_mode false -mpegts_flags system_b; works in FFMbc with -fflags +genpts specified. TS→mp4 succeeded in FFMbc (0.7.2) with -fflags +genpts -f mp4 specified. The ffmbc hack worked for this file and some others, the rest still failed. The issue appears to be centered around timestamping. A new question has been posted to supercede this one. – user786008 Feb 4 '18 at 13:20

To answer part of your question (and add a couple of other abbreviations you will run into):

  • PTS = Presentation Time Stamp
  • DTS = Decode Time Stamp
  • PCR = Program Clock Reference
  • SCR = System Clock Reference

MPEG elementary streams reorder the frames for transmission. The PTS indicates the order that the frames should be re-assembled into. The DTS lets the decoder know if a frame needs to be decoded earlier than it is displayed (because a P or B frame references it). The PCR or SCR are the time scale that the PTS and DTS reference.

tstools and other transport stream analyzers can help you determine if the PCR/PTS/DTS issue is in the source file or not.

  • The links you've provided are just fabulous! However, I'm getting more confused after reading the PDF pp. 43-44. Although the PTS may not be monotonous as a result of bidirectional encoding, this should not cause frustrations for a proper (de)muxer because (i) the stream is transmitted and received according to the DTS which has to be (a) monotonous and (b) <= PTS-1, and (ii) every field has to have a meaningful PTS. If the million "pts has no value" and "non-monotonous DTS" in FFMpeg are real, how possible could it be to have a flawless playback of the original ts file (which I have)? – user786008 Feb 1 '18 at 4:11
  • It definitely isn't likely for there to be a source problem that isn't picked up during playback and only happens during transcode. But when I want to be sure about something in a transport stream, I run it through an analyzer. Sometimes you pick up on something that is subtlety wrong that one decoder can correct that another chokes on. – Michael Liebman Feb 1 '18 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.