GNOME Bugzilla – Bug 632877
[ffdec_h264] always outputs same timestamp
Last modified: 2010-10-22 11:07:12 UTC
Created attachment 172988 [details] video.gdp If the attached file is played with ffdec_h264, the decoder start placing the same timestamp from 0:00:02.304444182. But it doesn't look like there should be a reason to timestamp always with the same. Incomming timestamps in the decoder are increasing. gst-launch filesrc location=/tmp/video.gdp ! gdpdepay ! ffdec_h264 ! fakesink -v | grep chain | sed 's/^.* (\([0-9]*.*\), d.*$/\1/' 518400 bytes, timestamp: none 518400 bytes, timestamp: 0:00:00.033366666 518400 bytes, timestamp: 0:00:00.075479340 518400 bytes, timestamp: 0:00:00.108559667 ... 518400 bytes, timestamp: 0:00:02.204350118 518400 bytes, timestamp: 0:00:02.237718566 518400 bytes, timestamp: 0:00:02.271086956 518400 bytes, timestamp: 0:00:02.304444182 518400 bytes, timestamp: 0:00:02.304444182 518400 bytes, timestamp: 0:00:02.304444182 ...
One of those buffers has a duration of 0 and that seems to screw things up.
That's related to the fact that ffmpeg decoders doesn't respect the input timestamp and calculates de next TS like TS + duration, causing desyncs if the source doesn't respect strictly the framerate or if it drops buffers.
the big problem is that ffdec has to guess if the input timestamps are DTS or PTS. The current algorithm assumes DTS until it sees reordered timestamps. In this particular case, it should reset next_out to -1 when the duration was unset and it should probably also ignore a duration of 0.
commit cc2a6e493bdc93cb23e71a5d519087aa4a648357 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Oct 22 12:59:02 2010 +0200 ffdec: be more careful with DTS timestamp interpolation Don't use -1 and 0 duration buffers to calculate next output timestamp as they are very likely wrong. Fixes #632877