GNOME Bugzilla – Bug 649369
basesrc: do not set first buffer timestamp to 0 for live sources
Last modified: 2011-05-12 17:17:05 UTC
Created attachment 187182 [details] [review] basesrc: do not set first buffer timestamp to 0 for live sources Doing so avoids a large timestamp gap between first and second buffer for live sources which take time to start up. The first buffer now has a "live" timestamp based on the running time, as other buffers do.
do we need to go through the gst_base_src_is_live() method (instead of just checking ->is_live) at that point ? It would avoid taking/releasing the object lock. Otherwise it makes sense
Created attachment 187195 [details] [review] Uses is_live directly Updated to use is_live directly.
Do we want this in 0.10.33?
I've pushed this now for the quick-fix 0.10.34 release (since we're doing one anyway, we may just as well put this in): commit 03050fd71ddede6980440ec205678b068f84a738 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Wed May 4 15:31:56 2011 +0300 basesrc: do not set first buffer timestamp to 0 for live sources Doing so avoids a large timestamp gap between first and second buffer for live sources which take time to start up. The first buffer now has a "live" timestamp based on the running time, as other buffers do. https://bugzilla.gnome.org/show_bug.cgi?id=649369 Some more context: <tpm> that basesrc is-live timestamp patch, what exactly does it actually fix? (what elements?) <v> my particular case was a shmsrc. It would emit its first buffer a while after being started. <v> The first buffer would get retimstamped to 0, and the second would have its 23 seconds timestamp left.