GNOME Bugzilla – Bug 604095
gstpad: Make sure that unlinked pads do not return FALSE on latency events
Last modified: 2012-06-06 11:26:32 UTC
Created attachment 149355 [details] [review] patch Latency configuration should not be messed up because of non-linked pads. In general, one return FALSE on latency distribution causes the "overall" pipeline latency configuration to fail.
The patch looks good but could you fix the mail address and name please? :)
Created attachment 149405 [details] [review] patch
Created attachment 149406 [details] [review] patch hm, it did not like my Norwegian "å" :)
I don't quite know what to do with this bug. I would say that when something is not linked, there is a big chance that some elements might not receive the right latency event and that things can fail. On the other hand, the latency event is only sent when the latency query returns TRUE. The latency query of course returns FALSE when something is unlinked. so here you have a case of unlinked pads where the latency query returned TRUE?
In farsight & co, I am very careful to not add sinks before they can be linked all the way to the source to prevent that problem. Imho, the current behavior is correct.
Håvard, can you address the questions raised in comment #4?
Yes. If we take gst_bin_do_latency_func() as the example, the latency query does not check its return value, so there is nothing "failing" there. The latency query will most likely have returned false, but this is really irrelevant. The problem boils down to a inherent dynamic link-race for all pipelines. Any time you attach a src to a pipeline, you have to make sure that all downstream is linked properly, or you can (and probably will) get a FLOW_UNLINKED, and the src will stop. However, then you will be adding a sink that could fire an upstream-event, and without the src in place, this would fail, and for latency that has consequences. Also, by removing a src from a running pipeline, you risk the same thing. We needed this patch because we do a lot of dynamic linking, and we still want the latency to be configured properly.
BUMP! ;-) Thoughts anyone?
ping again ;)
commit a4b9b79c960bf39eb7307984da80dcd642e60993 Author: Havard Graff <havard.graff@tandberg.com> Date: Tue Oct 13 17:24:34 2009 +0200 Make sure that unlinked pads do not cause a return false on latency events. Context: Latency configuration should not be messed up because of not-linked pads. In general, one return FALSE on latency distribution causes the "overall" pipeline latency configuration to fail. This shows up as noise in logs (warning).