Answers.Body: <p>To answer part of your question (and add a couple of other abbreviations you will run into):</p>
  
  <ul>
  <li>PTS = Presentation Time Stamp</li>
  <li>DTS = Decode Time Stamp</li>
  <li>PCR = Program Clock Reference</li>
  <li>SCR = System Clock Reference</li>
  </ul>
  
  <p><a href="http://download.tek.com/document/25W-11418-10.pdf" rel="nofollow noreferrer">MPEG elementary streams</a> 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.</p>
  
  <p><a href="https://github.com/OlivierLeBozec/tstools" rel="nofollow noreferrer">tstools</a> and other transport stream analyzers can help you determine if the PCR/PTS/DTS issue is in the source file or not.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-01T04:11:54.930Z
Answers.Text: 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)?
Answers.UserDisplayName: user786008
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-01T21:08:41.640Z
Answers.Text: 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.
Answers.UserDisplayName: Michael Liebman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-01T01:36:59.903Z
Answers.LastActivityDate: 2018-02-01T01:36:59.903Z
Answers.UserDisplayName: Michael Liebman
Body: <p>NOTE: This question is superceded by <a href="https://video.stackexchange.com/q/23344/">this new one</a>, please do not answer below this post.</p>
  
  <p><strong>What happened?</strong>  </p>
  
  <ul>
  <li><p>[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  </p></li>
  <li><p>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. </p></li>
  <li><p>[Update] Still another one in TS format of H.264/AAC@29.97p <em>can</em> be properly remuxed into isom/mp4 without a hitch, not requiring any ffmpeg switches other than -i, -c copy. </p></li>
  </ul>
  
  <p><strong>Technical details</strong>  </p>
  
  <ul>
  <li><p>FFMpeg reports millions of the following error messages, with or without any possible combination of these switches: -fflags +genpts, -fflags +igndts, -fflags +discardcorrupt  </p>
  
  <ul>
  <li>Command line is <code>ffmpeg.exe -fflags +igndts -fflags +genpts -fflags +discardcorrupt -i INPUT -c copy -format mp4 OUTPUT</code>  </li>
  <li>Error Message 1:<br>
      [mp4 @ address] pts has no value<br>
      Last message repeated xxx times  </li>
  <li>Error Message 2:<br>
     [mp4 @ address] Non-monotonous DTS in output stream 0:0. Previous ... Current ... Changing to ... , blah blah  </li>
  </ul></li>
  <li><p>AVIDemux completes operation with wrong metadata and faulty playback. File properties and playback behaviour resembles that created by FFMpeg  </p>
  
  <ul>
  <li>Frame-rate becomes variable, should be 50i  </li>
  <li>Average frame-rate is not the correct value, showing very strange numbers  </li>
  <li>Playback frame-rate is abnormal, oscillating btw. 59.94 and 39.xx  </li>
  </ul></li>
  <li><p>[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.  </p>
  
  <ul>
  <li>Command line is  <code>mp4box.exe -fps 50 -add "INPUT#video" OUTPUT</code>  </li>
  <li>Error Message:<br>
     [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  </li>
  </ul></li>
  </ul>
  
  <p><strong>My questions, in detail</strong>  </p>
  
  <p>1   What on earth is "DTS" and "PTS"? They seem to be obsructing a successful remux.<br>
  2   Is this due to corrupted file or software bug (see <a href="https://trac.ffmpeg.org/ticket/4768" rel="nofollow noreferrer">https://trac.ffmpeg.org/ticket/4768</a> and <a href="https://trac.ffmpeg.org/ticket/502" rel="nofollow noreferrer">https://trac.ffmpeg.org/ticket/502</a>)?<br>
  3   If this is a software bug what are the work-arounds?<br>
  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.  </p>
  
  <p><strong>Diagnostic Information</strong><br>
  -   MediaInfo dump of file1,  file2, and  file1 remuxed into mp4 by FFMpeg<br>
  <a href="http://pastebin.ca/3966322" rel="nofollow noreferrer">http://pastebin.ca/3966322</a></p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-31T16:33:03.790Z
Comments.Text: What does corrupted playback mean - decoding errors? Is the playback speed always wrong or it varies?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-01T03:24:43.820Z
Comments.Text: @Mulvya, playback speed is always wrong; frame image seems fine; the decoder can work but apparently the file isn't usable.
Comments.UserDisplayName: user786008
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-01T05:53:42.290Z
Comments.Text: Does a TS to TS remux preserve playback rate? The `store method` of file1 is unusual. Try with [ffmbc](https://github.com/bcoudurier/FFmbc). If you can't compile, get an older binary from https://www.videohelp.com/software/ffmbc
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-02-04T13:20:28.943Z
Comments.Text: @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](https://video.stackexchange.com/questions/23344/) has been posted to supercede this one.
Comments.UserDisplayName: user786008
Tags: <ffmpeg><mp4><file-formats><framerate><mpeg>
Title: Wrong frame-rate, corrupted playback of isom/mp4 files remuxed from H.264/AC3 MPEG-TS
UserDisplayName: user786008
ThreadText: # Wrong frame-rate, corrupted playback of isom/mp4 files remuxed from H.264/AC3 MPEG-TS
  
  (Asked by: username_0 on 2018-01-31)
  
  NOTE: This question is superceded by [this new one](https://video.stackexchange.com/q/23344/), 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  
  <http://pastebin.ca/3966322>
  
  **Tags:** ffmpeg, mp4, file-formats, framerate, mpeg
  
  > **Comments:**
  > **username_1**: What does corrupted playback mean - decoding errors? Is the playback speed always wrong or it varies?  
  > **username_0**: @Mulvya, playback speed is always wrong; frame image seems fine; the decoder can work but apparently the file isn't usable.  
  > **username_1**: Does a TS to TS remux preserve playback rate? The `store method` of file1 is unusual. Try with [ffmbc](https://github.com/bcoudurier/FFmbc). If you can't compile, get an older binary from https://www.videohelp.com/software/ffmbc  
  > **username_0**: @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](https://video.stackexchange.com/questions/23344/) has been posted to supercede this one.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-02-01. Score: 0 | Accepted answer
  
  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](http://download.tek.com/document/25W-11418-10.pdf) 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](https://github.com/OlivierLeBozec/tstools) and other transport stream analyzers can help you determine if the PCR/PTS/DTS issue is in the source file or not.
  
  > **Comments:**
  > **username_0**: 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)?  
  > **username_2**: 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.  
  
  ---
  
  