Update the sticky events on SRC ghostpads when retargeting. This ensures
that the ghostpad has the exect same sticky events as the target pad. We
don't want to do this for SINK ghostpads, they got the events from
downstream and we don't want to overwrite them with the target pad
events.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=707621
gst_parse_launchv, gst_parse_launchv_full and gst_parse_launch_full
all return floating refs, the same as gst_parse_launch, which just
calls gst_parse_launch_full internally anyway.
Add a unit test assertion to check it's true.
Spotted by nemequ on IRC.
Since the refactoring of GstContext (commits
qc9fa2771b508e9aaeecc700e66e958190476f,
a7f5dc8b8a,
690326f906dc82e41ea58b81cdb2e3e88b754,
d367dc1b0d4ecb37f4d27267e03d7bf0c6c06a6, and
82d158aed3f2e8545e1e7d35085085ff58f18) I am no longer able to get
a shared context for an element that is used twice in a pipeline.
I used the documentation and eglglessink as my reference for
implementing the GstContext logic.
As the code was tied to a hardware decoder, I have ported the
GstContext code to fakesink to show the problem. Using the old
API a single ExampleMgr instance is created, but using the new
API each element is creating its own instance.
pads->data is the public list. It is dynamically rebuilt at each call to
check_collected, in check_pads to be specific. When you add a pad and
collectpads have been started, it is not added to the public list.
Thus there exists a possible race where :
1) You would add a pad to collectpads while running.
2) You set collectpads to flushing before check_collected has been called again
-> the pad is not set to flushing
3) the pad starts pushing data as downstream might not be prepared, in the case
of adder it then returns FLOW_FLUSHING.
4) elements like demuxers, when they get a FLOW_FLUSHING, stop their tasks,
never to be seen again.
https://bugzilla.gnome.org/show_bug.cgi?id=708636
For some rare cases, one might not be able to use the hardcoded $HOME/gst
location yet would still want to use the gst-uninstalled script as-is (which
has the benefit of being constantly updated).
For these cases, the checkout directory can be specified with the
GST_UNINSTALLED_ROOT environment variable.
Ex:
export GST_UNINSTALLED_ROOT=$HOME/somewhere/with/checkouts
And then just call gst-uninstalled directly:
$GST_UNINSTALLED_ROOT/gstreamer/gst-uninstalled
