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 310447 - incorrect time change
incorrect time change
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.8.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-15 07:09 UTC by Josef Zlomek
Modified: 2005-08-29 15:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch for gst_element_wait() (785 bytes, patch)
2005-07-15 07:10 UTC, Josef Zlomek 		none Details | Review
Very simple test program. (2.06 KB, text/plain)
2005-07-15 12:10 UTC, Josef Zlomek 		  Details

Description Josef Zlomek 2005-07-15 07:09:47 UTC 
When waiting for future timestamp, the function gst_element_wait wrongly
computes the target time. The problem is that it adds the element->base_time to
the timestamp which results in timestamp far in the future. Gstreamer starts
reading the input and is waiting for this far time and thus deos nothing useful.

I have added more debug dumps and got the following times. It is obvoius that
gstreamer should wait for timestamp and not for element->base_time + timestano.

gstelement.c(938):gst_element_wait:<demuxer> element time 1:25:18.889187333
gstelement.c(940):gst_element_wait:<demuxer> element base time
311491:34:12.731328667
gstelement.c(942):gst_element_wait:<demuxer> timestamp 1:25:18.891833333

The attached patch fixes this bug.
Comment 1 Josef Zlomek 2005-07-15 07:10:33 UTC 
Created attachment 49208 [details] [review]
Patch for gst_element_wait()
Comment 2 Ronald Bultje 2005-07-15 08:56:45 UTC 
This is almost certainly wrong. When are you seeing problems with this? How can
we reproduce?
Comment 3 Josef Zlomek 2005-07-15 09:08:30 UTC 
The problems occurs probably when one frame is lost (skipped) in the mpeg file.
I can send you a short video file that uncoveres this bug.
It should be enough to connect fdsrc with mpegdemux.
Comment 4 Josef Zlomek 2005-07-15 12:10:31 UTC 
Created attachment 49226 [details]
Very simple test program.
Comment 5 Josef Zlomek 2005-07-19 12:07:41 UTC 
The problem was that the timestamps in mpeg overflow and cause a time seek to
far future.