The gst_dash_demux_stream_update_fragment_info function could call
gst_dash_demux_stream_update_headers_info function twice. The
gst_dash_demux_stream_update_headers_info function will set header_uri and
index_uri to some newly allocated strings. The values set by the first call of
gst_dash_demux_stream_update_headers_info will leak when the function is
called for a second time.
The solution is to call gst_adaptive_demux_stream_fragment_clear before the
second call of gst_dash_demux_stream_update_headers_info
https://bugzilla.gnome.org/show_bug.cgi?id=753188
Check if profile is NULL before dereferencing it with new. Also, new will
never return NULL; if allocation fails, a std::bad_alloc exception will be
thrown instead. Remove check for a NULL return.
CID #1315258
Also implement framerate handling correctly by borrowing the code from
ximagesrc. GstBaseSrc::get_times() can't be used for that, we have to
implement proper waiting ourselves.
The ref_object and object parameters were the wrong way around.
For the typical use case where an application is setting a
GstControlBinding on the returned ghost pad:
1. our control binding would be removed when the new one was set
2. sync_values calls were not being forwarded from the internal
pad to the ghost pad.
If an application attempts to perform other control binding
operations (get_* family of functions) on the internal pad, they
will also be forwarded to the ghost pad where a possible
GstControlBinding will provide the necessary values.
Only copy the values from the parent if the current node doesn't
have that value, they were being copied from the parent and
then overwriten by the child node, leaking the parent's copy
This other type of baseURL test was replaced by a more complex one,
better have both to keep both options working
Also adds another 2 variations of how baseURL can be generated
https://bugzilla.gnome.org/show_bug.cgi?id=752776
With the switch of gstopencv.c to C++, all OpenCV elements are built with
g++. The template variable clashes with C++'s feature of the same name.
Rename template to templ to avoid any clash.
The cascade classifier changes its structure on new version of OpenCV.
The need to migrate to C++ to utilize the new load method of OpenCV which
allows to load the new classifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=748377
The block that is dispatched async to the main thread assumed the
wrapping GstAvSampleVideoSink to be alive. However, at the time of
the block execution the GstObject instance that is deferenced to access
the CA layer might already be freed, which caused occasional crashes.
Instead, we now only pass the CoreAnimation layer that needs to be
released to the block. We use __block to make sure the block is not
increasing the refcount of the CA layer again on its own.
https://bugzilla.gnome.org/show_bug.cgi?id=753081
In the case where you have a source giving the GstAggregator smaller
buffers than it uses, when it reaches a timeout, it will consume the
first buffer, then try to read another buffer for the pad. If the
previous element is not fast enough, it may get the next buffer even
though it may be queued just before. To prevent that race, the easiest
solution is to move the queue inside the GstAggregatorPad itself. It
also means that there is no need for strange code cause by increasing
the min latency without increasing the max latency proportionally.
This also means queuing the synchronized events and possibly acting
on them on the src task.
https://bugzilla.gnome.org/show_bug.cgi?id=745768
VPS is not mandatory, and need not check for its presence before setting
the caps. Because of the check, in streams which don't have VPS,
sticky event mishandling happens.
https://bugzilla.gnome.org/show_bug.cgi?id=752807
In media to caps function, reserved_keys array is being used for variable i,
leading to GLib-CRITICAL **: g_ascii_strcasecmp: assertion 's1 != NULL' failed
changed it to variable j
https://bugzilla.gnome.org/show_bug.cgi?id=753009
We can't know if the GstGLUpload type is initialized at this point already,
and thus our debug category might not be initialized yet... and cause an
assertion here.
As we don't print debug output for any of the other transform functions, let's
defer this problem for now.
Before aggregator based elements always started at running time 0,
now it's possible to select the first input buffer running time or
explicitly set a start-time value.
https://bugzilla.gnome.org/show_bug.cgi?id=749966
