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.
Since the default number of max unused threads in GThreadPool has been
changed from 0 to 2 it needs to be set to 0 to stop all threads or
valgrind will report them as memory leaks.
The change should have been from PARAM_CONSTRUCT_ONLY to
PARAM_CONSTRUCT, otherwise bindings are affected, since
they look for the CONSTRUCT flag.
See ec55363d
In some cases the wait for more data was happening without updating
the buffering state, meaning the API user would not be able to notice
it should pause the pipeline and update UI to indicate that is the
case, the video would likely stutter instead.
https://bugzilla.gnome.org/show_bug.cgi?id=707648
The seqnum of the segment after a seek should be the same of
the seek event. Downstream elements might rely on seqnums to
identify events related to a seek.
This is particularly important when a demuxer maps a TIME seek
into a BYTES seek for upstream and it needs to identify the
corresponding segment event and map it back into TIME to push
downstream, possibly using the values from the original seek
event.
https://bugzilla.gnome.org/show_bug.cgi?id=707530
If a pad is removed while a collectpads element (say adder) is in a chain
function waiting to be collected, there is a possibility that an unref happens
on a NULL pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=707536
If the multiqueue has automatically grown chances are good that
we will cause the pipeline to starve if the maximum level is reduced
below that automatically grown size.
https://bugzilla.gnome.org/show_bug.cgi?id=707156
