Where do you see non-monotonically increasing timestamps?

I can reproduce the issue with the German track (audio_00), but it looks like it's just that there's too much jitter. It works fine for me with pulsesink drift-tolerance=80000

DTS seems to be really restricted format. There is no variable bitrate or variable blocksize. I assume there should be no GAPs between frames.
It is defined that each block has 256 samples and it seems like muxing app or encoder  calculated wrong time, since the time difference is equal to 255 samples per block.

IMHO. On one sight i assume the encoder or muxer war brocken (this file was created 2008)

On other side, with all restrictions DTS has, there is no sense to use timestamps from container.

I just disabled this part of the code and it played this stream without any GAP and clicks:

diff --git a/ext/dts/gstdtsdec.c b/ext/dts/gstdtsdec.c
index 2039c58..0bbe632 100644
--- a/ext/dts/gstdtsdec.c
+++ b/ext/dts/gstdtsdec.c
@@ -800,13 +800,13 @@ gst_dtsdec_chain_raw (GstPad * pad, GstBuffer * buf)
   }
 
   /* merge with cache, if any. Also make sure timestamps match */
-  if (GST_BUFFER_TIMESTAMP_IS_VALID (buf)) {
+/*  if (GST_BUFFER_TIMESTAMP_IS_VALID (buf)) {
     dts->time = GST_BUFFER_TIMESTAMP (buf);
     GST_DEBUG_OBJECT (dts,
         "Received buffer with ts %" GST_TIME_FORMAT " duration %"
         GST_TIME_FORMAT, GST_TIME_ARGS (GST_BUFFER_TIMESTAMP (buf)),
         GST_TIME_ARGS (GST_BUFFER_DURATION (buf)));
-  }
+  } */
 
   if (dts->cache) {
     buf = gst_buffer_join (dts->cache, buf);

but i think this patch will brake things after seek.

Created attachment 192249 [details] [review]
patch v1

Patch to make dtsdec more robust against brocken timestamps.

Could anybody review the patch?

Review of attachment 192249 [details] [review]:

::: ext/dts/gstdtsdec.c
@@ +810,3 @@
         GST_TIME_ARGS (GST_BUFFER_DURATION (buf)));
+
+    /* There are two possible bugs: time from container can be bigger als,

s/als/as/

@@ +811,3 @@
+
+    /* There are two possible bugs: time from container can be bigger als,
+     * real time of stream, so there is silent; or less, then it is an

s/so so there is silent/so that there is silence/

@@ +813,3 @@
+     * real time of stream, so there is silent; or less, then it is an
+     * overlap */
+    /* time overlap - contaniers timestamp is defenetly  brocken.

s/contaniers/containers/
s/defenetly/definitively/
s/brocken/broken/

@@ +814,3 @@
+     * overlap */
+    /* time overlap - contaniers timestamp is defenetly  brocken.
+     * Ignor it as long as possible,

s/Ignor/Ignore/

@@ +816,3 @@
+     * Ignor it as long as possible,
+     * for example: 4096 samples = 16 * 256 dts blocks */
+    if (container_ts + sample_time * 4096 < dts->time) {

It would be nice to have a simple define somewhere for the tolerance. Could be in audio.h / video.h. Do we need different values for audio/video?
Anyway I think this should be in time and not in samples.

@@ +818,3 @@
+    if (container_ts + sample_time * 4096 < dts->time) {
+      GST_DEBUG_OBJECT (dts, "overlaping samples: %lli",
+    /* time overlap - contaniers timestamp is defenetly  brocken.

please use the GLIB macros "samples %"G_GINT64_TIME_FORMAT, GST_CLOCK_DIFF(...)

@@ +824,3 @@
+      /* we can tollerate small GAPs */
+      GST_DEBUG_OBJECT (dts, "GAP samples: %lli",
+    if (container_ts + sample_time * 4096 < dts->time) {

here too.

Oops (sort of); dtsdec was just recently ported to GstAudioDecoder, which renders this patch and kind of tricks mute (as it then comes with its own standard jitter/tolerance handling and property).

In particular, setting the tolerance properly (on the decoder, similar to pulsesink as indicated above) should then work out (though unable to test as link seems no longer accessible).

Okay, Andreas, please retest and close bug if it works now.

sorry i don't have that particular file anymore :(

I've just re-tested it and it sounds fine now.