<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>

CC BY-SA 3.0
2018-02-01T04:11:54.930Z
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
CC BY-SA 3.0
2018-02-01T21:08:41.640Z
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
CC BY-SA 3.0
2018-02-01T01:36:59.903Z
2018-02-01T01:36:59.903Z
Michael Liebman
<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>

CC BY-SA 3.0
2018-01-31T16:33:03.790Z
What does corrupted playback mean - decoding errors? Is the playback speed always wrong or it varies?
Gyan
CC BY-SA 3.0
2018-02-01T03:24:43.820Z
@Mulvya, playback speed is always wrong; frame image seems fine; the decoder can work but apparently the file isn't usable.
user786008
CC BY-SA 3.0
2018-02-01T05:53:42.290Z
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
Gyan
CC BY-SA 3.0
2018-02-04T13:20:28.943Z
@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.
user786008
<ffmpeg><mp4><file-formats><framerate><mpeg>
Wrong frame-rate, corrupted playback of isom/mp4 files remuxed from H.264/AC3 MPEG-TS
user786008
# 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.  

---

