[Bug 699187] videorate ends up outputting buffers with incorrect duration.
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Wed May 8 11:30:22 PDT 2013
https://bugzilla.gnome.org/show_bug.cgi?id=699187
GStreamer | gst-plugins-base | git
--- Comment #10 from Mathieu Duponchelle <mathieu.duponchelle at epitech.eu> 2013-05-08 18:30:16 UTC ---
Ok so further debugging our problem in GES led me to think that we actually can
leave references to segment.base, as the calculated timestamp is actually
relative to the base:
GST_BUFFER_TIMESTAMP (outbuf) = push_ts - videorate->segment.base;
I started writing a test, and realized that the behaviour is correct, except
when we receive a segment, some buffers, then caps get set and a new segment is
received. In that case, in the _setcaps function, we do that :
l 525 :
gst_video_rate_swap_prev (videorate, NULL, GST_CLOCK_TIME_NONE);
which leads videorate->prevbuf to be NULL.
So when we get a segment event (l 676), we check if we have a prevbuf, and then
and only then we reset base_ts. This is wrong, as we should reset
out_frame_count and base_ts anyway. The attached patch will do that.
Another, separate problem is that this previous buffer should not be thrown
away, at least when caps are the same, and ideally never. I have no idea how to
do that though.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list