Change the gstcvdilate.c file extension to cpp and add it into Makefile for
consistency with other elements of opencv and because Opencv not support C
language in new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
Change the file extension to cpp and add it into Makefile for consistency
with other elements of opencv and because Opencv not support C language in
new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
Change the file extension to cpp and add it into Makefile for consistency
with other elements of opencv and because Opencv not support C language in
new API 2.4.11.
https://bugzilla.gnome.org/show_bug.cgi?id=754148
Change the gstretinex.c file to cpp and add it into Makefile.
It is necessary to migrate the retinex element to C++,
because new Opencv API leaves obsolete functions like cvSmooth.
This element uses this function.
You can see in this link:
http://docs.opencv.org/modules/imgproc/doc/filtering.html?
highlight=cvsmooth#void cvSmooth(const CvArr* src, CvArr* dst,
int smoothtype, int size1, int size2, double sigma1, double sigma2)
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=752528
Change the gsthanddetect.c file to cpp and add it into Makefile.
It is necessary to migrate the handdetect plugin to C++,
in order to load new and old classifiers, to make handdetect work
with newer versions of Opencv.
https://bugzilla.gnome.org/show_bug.cgi?id=752528
This is mostly a copy/paste of the negotiation function in
basetextoverlay, which was improved recently to handle many more cases.
This will allow us to negotiate a window size with downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=753824
Doing the contrary has no effect and the consequence is that playback
will start with the lowest bitrate even if we can already handle
higher bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=755108
Not doing this can lead the demuxer to attempt downloading fragments
for an invalid start time. The server would then send a HTTP
Precondition failed error, the demuxer would try some more times to
download the invalid fragment and eventually error out.
https://bugzilla.gnome.org/show_bug.cgi?id=754523
Move the TAG defines directly into the code, not sure what
their purposes is, these are printf format strings so having
them directly as literals in the code where they're used
makes the code easier to follow.
Remove playlist_str GString variable from GstM3U8Playlist struct,
since it's only used temporarily in playlist_render(). Might just
as well keep it local then.
Transform is set to be done in place in gstcvdilateerode.c, so the in-place
transform function is always used and the other is redundant. Removing it.
https://bugzilla.gnome.org/show_bug.cgi?id=753885
Transform is set to be done in place in gstcvdilateerode.c, so the in-place
transform function is always used and the other is redundant. Removing it.
https://bugzilla.gnome.org/show_bug.cgi?id=753885
When running GStreamer from uninstalled sources, the location of the haar
cascade files will be local. Check if running in uninstalled and set the
file paths accordingly.
Move handling of a GstSample in a separate function, and unref the
sample after calling it. libass copies the font data so we don't need to
keep it around.
https://bugzilla.gnome.org/show_bug.cgi?id=755759
Ignore the normal gap threshold for laggy streams and
immediately catch all streams up to the end of the segment
when processing gap updates for a segment during a
still frame sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=755680
Create src pads for Representations that contain timed-text subtitles,
both when the subtitles are encapsulated in ISO BMFF (i.e., the
Representation has mimeType "application/mp4") and when they are
unencapsulated (i.e., the Representation has mimeType
"application/ttml+xml").
https://bugzilla.gnome.org/show_bug.cgi?id=747774
The same has to be done for AdaptationSet and SegmentList nodes still.
Also this does not correctly implement the semantics: by default Period (and
other nodes) should only be loaded when needed, not in the very beginning. We
need to implement lazy loading for them, which means adjusting
gst_mpd_client_setup_media_presentation().
https://bugzilla.gnome.org/show_bug.cgi?id=752230
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
Some live streams (eg youtube) don't remove fragments in order to allow
seeking back in time (live + vod).
When gst_m3u8_client_has_next_fragment is called, we are getting wrong fragment
because current_file points in first file of the fragments list resulting in
watching the stream from the beginning again.
This patch sets current_file to nth fragment for live streams, then on
gst_m3u8_client_has_next_fragment will keep up with the live stream.
https://bugzilla.gnome.org/show_bug.cgi?id=753344
This allow properly copying selected meta, like the composition
overlay. Note that output buffer need to be readable, but GlUpload
keeps a ref. For now, simply drop GlUpload ref after perform,
leaving that ref has no purpose. The method shall be removed
in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=754047
Use base class default method instead of only copying flags and
timestamp. This way, selected meta's like compostion overlay will
be passed downstream as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=754047
During allocation query, when this element is not passthrough, it must
relay the overlay compostion meta and it's parameters. Fortunatly, base
transform can do this for us.
https://bugzilla.gnome.org/show_bug.cgi?id=753850
Previous patch did not handle the case where an encoding (e.g. UTF-8) is
specified in the <xml ?> element. Added an extra test for with and without
encoding.
https://bugzilla.gnome.org/show_bug.cgi?id=753813
When running on an STB, the function
gst_mpdparser_get_xml_node_as_string causes a segmentation fault. This
code works correctly on a Linux desktop.
Looking at the libxml documentation, the xmlNodeDump is deprecated.
Replacing the use of xmlNodeDump with xmlNodeDumpOutput fixes the
segfault on the STB and removes the use of the deprecated function.
Some distributions store OpenCV files in /usr/share/opencv and some others
(and default when building from source) install them in
/usr/share/OpenCV. Support both to find cascade files.
https://bugzilla.gnome.org/show_bug.cgi?id=753651
It is faster than doing a query that propagates downstream and
should be enough
Elements: faac, gsmenc, opusenc, sbcenc, voamrwbenc, adpcmenc, sirenenc
When seeking to the last second of a mpd it would reject the seek
because the comparison was < instead of <=
This fails the important use case of seeking to the end of a file
to play it back in reverse from the end
We need to keep the active buffer (the one we have retreive a
texture id from) otherwise it's racy and upstream may upload
new content before we have rendered or during later redisplay.
The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation
uses an HTTP HEAD request to a specified URL and then parses the
Date: HTTP response header.
This commit adds support to dashdemux for this method of time
synchronisation by making a HEAD request and then parsing the Date:
response.
This commit adds support to gstfragment to return the HTTP headers
and to uridownloader to support HEAD requests. To avoid creating a
new API, the RANGE get function is re-used (abused?) with start=-1
and end=-1 to indicate a HEAD request.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
This commit addresses the following items from the code review:
use a portable way to define NTP_TO_UNIX_EPOCH,
fix memory leak on error, and
add documentation to UTCTiming parse functions
Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead.
If an error occurs during DNS resolution, the GError was not being
released, causing a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
Unless the DASH client can compensate for the difference between its
clock and the clock used by the server, the client might request
fragments that either not yet on the server or fragments that have
already been expired from the server. This is an issue because these
requests can propagate all the way back to the origin
ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow
a DASH client to track the clock used by the server generating the
DASH stream. Multiple UTCTiming elements might be present, to indicate
support for multiple methods of UTC time gathering. Each element can
contain a white space separated list of URLs that can be contacted
to discover the UTC time from the server's perspective.
This commit provides parsing of UTCTiming elements, unit tests of this
parsing and a function to poll a time server. This function
supports the following methods:
urn:mpeg:dash:utc:ntp:2014
urn:mpeg:dash:utc:http-xsdate:2014
urn:mpeg:dash:utc:http-iso:2014
urn:mpeg:dash:utc:http-ntp:2014
The manifest update task is used to poll the clock time server,
to save having to create a new thread.
When choosing the starting fragment number and when waiting for a
fragment to become available, the difference between the server's idea
of UTC and the client's idea of UTC is taken into account. For example,
if the server's time is behind the client's idea of UTC, we wait for
longer before requesting a fragment
[PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068
dashdemux: support NTP time servers in UTCTiming elements
Use the gst_ntp_clock to support the use of an NTP server.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
This reverts commit ff11a1a8a0.
It can't be assumed that all buffers in a buffer list have the same SSRC or
are RTP or RTCP only. It has to be checked for every single buffer, and one
basically has to do the processing that is done by the default chain_list
implementation.
The current code was ignoring the par/dar aspect when transforming
from window coordinates to stream coordinates resulting in incorrect
coordinates being sent upstream in the navigation events.
