GNOME Bugzilla – Bug 682973
[videotestsrc] keep track of the correct running time after renegotiations
Last modified: 2012-09-23 17:07:40 UTC
Fixes renegotiation scenarios for videotestsrc timestamping when framerate changes
Created attachment 222826 [details] [review] videotestsrc: keep track of the correct running time after renegotiations Need to store the old running time and frame numbers when renegotiating and start from 0 again when a new caps is set, preventing that framerate changes cause timestamping issues. For example, if a stream pushed 10 buffers on framerate=2/1, its running time will be 5s. If a new framerate of 1/1 is set, it would make the running time go to 10s as it would count those 10 buffers as being sent on this new framerate.
This patch fixes the remaining failing test for camerabin. Tim suggested I could look at the new GstSegment.base field, but that is summed to the running_time after the rate multiplication. So that means that I should send a segment event with the current running_time as the base time? Is this how this field should be used?
I don't know off the top of my head. Will mark as blocker for now, so we don't forget. Current patch could go in even if there's a better way IMHO.
commit 386206e627b45fb7c6d64dec188ddf67ad80c1da Author: Thiago Santos <thiago.sousa.santos@collabora.com> Date: Wed Aug 29 16:02:11 2012 -0300 videotestsrc: keep track of the correct running time after renegotiations Need to store the old running time and frame numbers when renegotiating and start from 0 again when a new caps is set, preventing that framerate changes cause timestamping issues. For example, if a stream pushed 10 buffers on framerate=2/1, its running time will be 5s. If a new framerate of 1/1 is set, it would make the running time go to 10s as it would count those 10 buffers as being sent on this new framerate. Fixes camerbin unit test. https://bugzilla.gnome.org/show_bug.cgi?id=682973