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 323392 - gstvideorate is pushing buffers with invalid timestamps
gstvideorate is pushing buffers with invalid timestamps
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-06 18:27 UTC by Sebastien Cote
Modified: 2006-01-13 15:35 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed fix (578 bytes, patch)
2005-12-06 18:28 UTC, Sebastien Cote
none Details | Review

Description Sebastien Cote 2005-12-06 18:27:08 UTC
The gstvideorate element is sending buffers with invalid timestamps relative to
the current segment (all the buffers it sends are relative to 0). When it
receives a NEW_SEGMENT event, it pushes this event without changing the timestamps. 

It should either modify the timestamps in the event, or make the timestamps of
the output buffers relative to the segment's timestamp.
Comment 1 Sebastien Cote 2005-12-06 18:28:15 UTC
Created attachment 55699 [details] [review]
proposed fix

When a NEW_SEGMENT event is received, unref it and push a new NEW_SEGMENT event
with a timestamp of 0.
Comment 2 Edward Hervey 2005-12-06 19:37:49 UTC
It should modify the timestamps of the buffer and not assume that the segment
starts at 0 (as it is still doing now)
Comment 3 Sebastien Cote 2005-12-07 01:58:45 UTC
Well, it does not assume the segment starts at 0, it forces the segment to start
at 0 (for downstream elements). The timestamp of videorate's first buffer will
always be 0 because the new segment's timestamp is substracted from the buffer's
timestamp.

It guess having the first buffer use the segment's timestamp might be a nicer
solution, but the end result would be the same.
Comment 4 Sebastien Cote 2006-01-03 17:41:59 UTC
This bug was fixed in 0.10.1