[Bug 654844] dts streams with non monotonically increasing timestamps from mkv containers sound broken

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Jul 18 08:25:47 PDT 2011


https://bugzilla.gnome.org/show_bug.cgi?id=654844
  GStreamer | don't know | 0.10.34

Alexey Fisher <bug-track> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bug-track at fisher-privat.net

--- Comment #2 from Alexey Fisher <bug-track at fisher-privat.net> 2011-07-18 15:25:44 UTC ---
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);

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list