GNOME Bugzilla – Bug 646397
rtpjitterbuffer base_time broken by commit f84b8a69
Last modified: 2011-04-04 09:54:46 UTC
In this commit, the element calls gst_element_set_base_time(), this sounds very wrong to me. This breaks down if you add the jitterbuffer to a running pipeline. The source and jitterbuffer then have a different idea of the base time (so of the running time too), so the jitterbuffer is late by the difference between its base time and the source's basetime. So every synced buffer is late by that difference. Reverting the patch fixes this bug (and well, I don't understand how RTSP playback words so I can't figure out what the patch is trying to accomplish).
(part of) problem is all the "live stuff" that happens in rtsp(src) even when very much non-live material is being played. In particular, for seeking in this case, all (syncing/timing) that happens in the pipeline before it prerolls again (following the flush) still happens with old base_time (which will be set to new base_time when the whole pipeline goes to playing again). As such, it might think it is timing out to eos during the seek. So, if there are suggestions how to have jitterbuffer recognize difference between being added and what follows a flush(ing seek) ... Will ponder about that and as to whether it might be controlled elsewhere, but suffice it to say e.g. having to make rtspsrc specifically aware of jitterbuffer mechanics is not so nice ...
OK, so regression fixed by revert: commit e5bcaa45e63a701be8f507efeb8cdcbd209ac54d Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Apr 4 11:35:59 2011 +0200 Revert "jitterbuffer: reset element base_time upon flush" This reverts commit f84b8a69cba9c538f5546869cb4ef454ad5efb9d. Fixes bug #646397. ... and then solved the original problem (as described above) this way: commit 226a7cb32e10cf057035348b616772bf539d2dc4 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Apr 4 11:27:29 2011 +0200 rtspsrc: distribute new base_time to manager children following flush seek ... by forcing a state changed to PLAYING, which should otherwise be a no-op as elements should already be in that state. In particular, jitterbuffer needs new base_time as soon as possible to perform proper timing (e.g. eos timeout handling) and can't wait for the new base_time that will be distributed when the whole pipeline returns to PLAYING. See bug #646397.