After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 632877 - [ffdec_h264] always outputs same timestamp
[ffdec_h264] always outputs same timestamp
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
0.10.x
Other Linux
: Normal normal
: 0.10.12
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-10-22 10:03 UTC by Thijs Vermeir
Modified: 2010-10-22 11:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
video.gdp (492.96 KB, application/octet-stream)
2010-10-22 10:03 UTC, Thijs Vermeir
Details

Description Thijs Vermeir 2010-10-22 10:03:53 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
...
Comment 1 Wim Taymans 2010-10-22 10:15:52 UTC
One of those buffers has a duration of 0 and that seems to screw things up.
Comment 2 Andoni Morales 2010-10-22 10:26:02 UTC
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.
Comment 3 Wim Taymans 2010-10-22 10:30:11 UTC
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.
Comment 4 Wim Taymans 2010-10-22 11:07:12 UTC
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