[gstreamer-bugs] [Bug 580796] [ffmpegdec] out-of-order timestamps

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=580796

  GStreamer | gst-ffmpeg | Ver: git




------- Comment #9 from vanista  2009-06-02 20:53 UTC -------
My use case is IPTV sources with HD feed using main profile (CABAC and
B-Frames) additionally the feed is interlaced, so for each display frame there
are a number of PES chunks.

Sorry I can't provide a capture, it's copyrighted. I tried replicating the
source using videotestsrc, x264enc and mpegtsmux but it looks like the mux
prevents timestamps from going back in time. I also tried plugging the decoder
right after the encoder and the ts come out reordered.

At least, here are the timestamps of the sample in cause :


mpegtsdemux ! fakesink :

[...]
 163 bytes, timestamp: 0:35:22.095200000
4048 bytes, timestamp: none
8096 bytes, timestamp: none
1963 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.111877777
5287 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.028466666
3535 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.045144444
3387 bytes, timestamp: none
 170 bytes, timestamp: 0:35:21.995100000
1063 bytes, timestamp: none
 170 bytes, timestamp: 0:35:22.011777777
1971 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.061833333
1870 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.078511111
 820 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.228666666
4048 bytes, timestamp: none
5157 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.245344444
7871 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.161933333
4118 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.178611111
4429 bytes, timestamp: none
 170 bytes, timestamp: 0:35:22.128566666
2268 bytes, timestamp: none
 170 bytes, timestamp: 0:35:22.145244444
2177 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.195300000
1664 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.211977777
2483 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.362133333
4048 bytes, timestamp: none
1811 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.378811111
5155 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.295400000
3029 bytes, timestamp: none
 165 bytes, timestamp: 0:35:22.312077777
[...]


mpegtsdemux ! ffdec_h264 ! fakesink :

345600 bytes, timestamp: 0:35:22.095200000
345600 bytes, timestamp: 0:35:22.128566666
345600 bytes, timestamp: 0:35:22.295400000
345600 bytes, timestamp: 0:35:22.228666666
345600 bytes, timestamp: 0:35:22.262033333
345600 bytes, timestamp: 0:35:22.295400000
345600 bytes, timestamp: 0:35:22.328766666
345600 bytes, timestamp: 0:35:22.362133333
345600 bytes, timestamp: 0:35:22.462233333
345600 bytes, timestamp: 0:35:22.428866666
345600 bytes, timestamp: 0:35:22.462233333
345600 bytes, timestamp: 0:35:22.495600000
345600 bytes, timestamp: 0:35:22.528966666
345600 bytes, timestamp: 0:35:22.562333333
345600 bytes, timestamp: 0:35:22.595700000
345600 bytes, timestamp: 0:35:22.662433333
345600 bytes, timestamp: 0:35:22.662433333
345600 bytes, timestamp: 0:35:22.896000000
345600 bytes, timestamp: 0:35:22.829266666
345600 bytes, timestamp: 0:35:22.762533333
345600 bytes, timestamp: 0:35:22.795900000
345600 bytes, timestamp: 0:35:22.829266666
345600 bytes, timestamp: 0:35:22.862633333
345600 bytes, timestamp: 0:35:22.896000000
345600 bytes, timestamp: 0:35:22.996100000
[...]


Within gstffmpeg the whole timestamp handling mechanism is pretty complex and
there are lots of different cases to cover. My approach was to figure out how
ffplay handles timestamps between demuxer and decoder. I strongly believe that
the reordered_opaque property is the key, but I won't claim that my
implementation with the circular list is perfect ;)

Fact of the matter is, I get a lot of cases where timestamps coming out of
ffdec do not match the intended timestamps, and ffplay works perfectly with
these same samples.

One thing that is twitchy about the implementation is the decoder's data
consumption tracking. If a decoder doesn't give accurate information about
this, the timestamps will be offset.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=580796.