GNOME Bugzilla – Bug 692950
"rtpjitterbuffer" properties can't be changed after pipeline is started
Last modified: 2013-02-11 11:21:29 UTC
Hi, properties of the "rtpjitterbuffer" module can't be changed after the pipeline was started. Since the pipeline is in state "Gst.State.PLAYING", properties of this module can't be changed, the pipeline must be destroyed and recreated to use another property. Also, stopping the pipeline setting the state "Gst.State.NULL" is not sufficient, and pipeline will not work after that, "Gst.State.PLAYING" can't restart the pipeline properly. I try to change the property "latency". For more information, see this mail on the mailing list: http://gstreamer-devel.966125.n4.nabble.com/rtpjitterbuffer-changing-latency-property-on-the-fly-doesn-t-work-td4658120.html
The latency property is definitely changeable while playing.. Does your application listen to the LATENCY message and react appropriately (which probably means calling gst_bin_recalculate_latency(pipeline)).
What Comment 1 says. This fixes the reuse: commit 6c4029357cf8118703b6491e9089d0ecb3123f35 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Feb 11 11:06:32 2013 +0100 opusdec: clear the state of the decoder Set the channels and rate back to their default values in _stop because they are used to renegotiate when needed. See https://bugzilla.gnome.org/show_bug.cgi?id=692950
@Olivier Crete: OK. It works when I do this (python): def SetLatency(self, latency): self.jbuf.set_property('latency', latency) self.pipeline.recalculate_latency() @Wim Taymans: Is that mean it is no longer necessary to call "gst_bin_recalculate_latency" when we update latency? As far as I know, we do not need to use hypothetical functions like "gst_bin_recalculate_bitrate" or "gst_bin_recalculate_bandwidth" when we update other properties like "bitrate" or "bandwidth" or anything else!