GNOME Bugzilla – Bug 750782
pipeline: Add gst_pipeline_set_latency(), getter and GObject property
Last modified: 2015-06-12 15:40:55 UTC
This overrides the default latency handling and configures the specified latency instead of the minimum latency that was returned from the LATENCY query.
Created attachment 305060 [details] [review] pipeline: Add gst_pipeline_set_latency(), getter and GObject property
Review of attachment 305060 [details] [review]: I was wondering if this shouldn't be "set_extra_latency()" that would would be a value added to the minimum. ::: gst/gstpipeline.c @@ +645,3 @@ + GST_ELEMENT_WARNING (pipeline, CORE, CLOCK, (NULL), + ("Configured latency is lower than detected minimum latency: configured %" + GST_TIME_FORMAT " < min %" GST_TIME_FORMAT, Shouldn't you error out in this case instead of trying to set an invalid latency?
(In reply to Olivier Crête from comment #2) > Review of attachment 305060 [details] [review] [review]: > > I was wondering if this shouldn't be "set_extra_latency()" that would would > be a value added to the minimum. In my case I want to configure exactly the same latency on multiple pipelines. > ::: gst/gstpipeline.c > @@ +645,3 @@ > + GST_ELEMENT_WARNING (pipeline, CORE, CLOCK, (NULL), > + ("Configured latency is lower than detected minimum latency: > configured %" > + GST_TIME_FORMAT " < min %" GST_TIME_FORMAT, > > Shouldn't you error out in this case instead of trying to set an invalid > latency? We also don't error out if min_latency > max_latency a few lines above
If min > max, then it's a problem in the pipeline. If the configured latency is lower than min, it's an error from the application.
I think setting the desired target value makes most sense as well, given the intended use. If someone wants to add extra latency they'd probably want to do that for a specific element or chain and not pipeline-wide? I also think there are somewhat valid scenarios where one might want to force a lower latency than the pipeline would otherwise negotiate automatically, e.g. with a tsdemux in the pipeline which always adds 700ms latency (because that's the worst case scenario), whereas in reality one could get away with much lower values).
My typical use-case for extra latency is udpsrc ! tsdemux ! queue ! decoder ! sink, without the extra latency, then it may never queue up anything. That said, I understand slomo's usecase was slightly different, I assume live synchronized playback of some kind. The other use case for the extra latency is also to account for processing latency without having to do max-lateness style tricks at the sink.
I think for your use case we have to implement something properly to report the processing times to the sinks. Maybe making them part of the latency query somehow. Such ad hoc solutions like hacking around this problem in the sink, with max-lateness or some do-latency overriding, is not really a proper solution IMHO.
It's a real problem though, I had to work around that a few times too already :)