gst_uri_join_strings() will return the second parameter if it is an absolute
URI. No need to do a (wrong) check if the URI is absolute or not beforehand.
https://bugzilla.gnome.org/show_bug.cgi?id=755134
In case the format changed fast and the pending format is different
than the currently set but the currently set is equal to the pending
one we could end up having mismatch between the finally set format
and the data stream format.
https://bugzilla.gnome.org/show_bug.cgi?id=755542
The spec defines these as signed in 5.3.9.6.1.
Since we don't support this behavior, warn and default to 0
(non repeating), which is the spec's default when the value
is not present.
https://bugzilla.gnome.org/show_bug.cgi?id=752480
Even if it doesn't actually advance the subfragment in the default way
for streams that have subfragments, it can help the base class to return
EOS when there is no more fragments instead of signaling it that it should
continue downloading.
https://bugzilla.gnome.org/show_bug.cgi?id=755042
This reverts commit 626a8f0a74.
This allows us to get the plain presentation offset and the period start time
separately. We have to adjust the timestamp by the presentation offset, but
the period start time should only adjust the stream time and running time.
https://bugzilla.gnome.org/show_bug.cgi?id=752409
This reverts commit e671ad25a9.
The timestamps should restart at 0 again for each period, but we have to
adjust the segment to map those timestamps to the actual stream time and
running time of that period.
Otherwise we would have timestamps that conflict with the ones from the tfdt
inside the MP4 container, which are restarting at 0 for each period.
https://bugzilla.gnome.org/show_bug.cgi?id=752409
In dash isombff profile the fragment is split into subframents where
bitrate switching is possible. Also take that into consideration
when checking if a stream has next fragments.
This GstStreamPeriod start value is expressed in nanoseconds,
and the glib time addition function expects microseconds.
There seems to have been a confusion with GstPeriodNode's start
field, which is expressed in milliseconds.
Additionally, add a warning if the timestamp modification did
not succeed, and NULL was returned.
The cvSmooth cvNot functions and do not have the correct input parameters.
Furthermore, cvSmooth function is not necessary for edge detection,
because the Canny function makes the step of smoothing the image.
And cvNot function is useless because there aren't changes if this
function is eliminated.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
The cascade classifier changes its structure on new version of OpenCV 2.4.11.
It is need to migrate to C++ to utilize the new load method of OpenCV which
allows to load the old and new classifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
For PROP_PROFILE case that exist inside gst_face_blur_set_property
function loads the new XML file in the CvHaarClassifierCascade property
without first checking that it is released because maybe there is an XML
file previously loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
Changes inside the gst_face_blur_load_profile function, the number of
input parameters and in lines where it is used due to it cannot be used
generically.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
Change the gstfaceblur.c file to cpp and add it into Makefile.
It is necessary to migrate the faceblur plugin to C++,
in order to load new and old classifiers, to make faceblur work
with newer versions of Opencv.
https://bugzilla.gnome.org/show_bug.cgi?id=753994
Fix some very dubious code. The class methods should always
be set, and the instance-specific check should then be done
inside the method. For data_received that's there already, for
finish_fragment we need to add it.
https://bugzilla.gnome.org/show_bug.cgi?id=753937
