GNOME Bugzilla – Bug 633088
[rtspsrc] tweak default jitterbuffer buffer mode
Last modified: 2010-12-10 11:44:52 UTC
Created attachment 173159 [details] jitterbuffer slave mode output timestamps log Default buffer mode passed down by rtspsrc is SLAVE, which works well for real-time low latency (i.e. live) streams. However, BUFFER is otherwise suitable for (non-live) streaming mode. In particular, when dealing with non-live streams (e.g. youtube stuff), clock slaving in jitterbuffer does not really make sense and leads to timestamps distortions in case of bursts. Attached log shows some jitterbuffer output timestamps that result from repeatedly pausing/playing some stream; the effect is that at each play resuming, some amount of time is "lost", which causes the data to run out well before actual EOS. In fact, also without repeated pause/play, the initial part is often lost, leading to shorter playback than actual duration.
Created attachment 173160 [details] [review] rtspsrc: add and use auto buffering mode Patch adds an auto buffering mode which selects BUFFER when a duration for the stream is known (unlikely live in that case), and SLAVE otherwise. Patch also changes default mode to the new auto mode, which might be argued to belong in a separate commit, or not to be done at all (being an API change, though it tends to Just Work this way ...)
Created attachment 175721 [details] [review] rtspsrc: add and use auto buffering mode As before, but some additional tweaks that fall back to slave method buffering for cases (known or expected) that do not handle the buffer method approach well.
commit 52b5929a2b7d4c0822ccd9611de28f7b7e2ffe9e Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Oct 25 11:51:06 2010 +0200 rtspsrc: add and use auto buffering mode ... which selects BUFFER for a non-live stream, and otherwise SLAVE. Fixes #633088.