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
It was unintuitive that GstContext was actually a list of different
contexts. GstContext now is only a type string and a structure to
contain the actual context.
Non-persistent contexts are removed when elements go back
to NULL state, persistent contexts are not. Applications
most likely want to set persistent contexts.
