This no longer does anything, and it was marked as CONSTRUCT_ONLY
which means someone would really have to go out of their way to
be able to set this, which would only be done in very custom
scenarios, if ever, and those will likely target a specific
version of GStreamer then, so probably not much point keeping
it deprecated for a while before removing it.
The Onvif Streaming Specification specifies that the NTP timestamps
in the Onvif extension header indicaes the absolute UTC time associated
with the access unit. But by using running time we can not achieve that,
since a frame's running time depends on the played interval, whether a
non-flushing is done, etc. Instead we have to use the stream time.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
It is now possible to update the currently used ntp-offset with a
custom serialized downstream event. The element will read the ntp-offset
property when doing the state transition from READY to PAUSED and
use that offset until it receives a "GstNtpOffset" event, which also
has a "ntp-offset" attribute in that it's structure. In case the
property is not set and no event has been received, the element will
guess the npt-offset with help of the clock. If no clock can be
retrieved, the element will error out and stop the data flow.
The same event is also used for updating the D/E-bits in the RTP
extension header. The discont flag in a buffer can be set whenver a
live/network source looses a frame, but that is not the type of
discontinuity that the onvif extension header should reflect. The
header is mainly used for playback of a track concept, in which
gaps can be present, and it's those kind of gaps that should be
highlighted with the D- and E-bits.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
If a buffer or a buffer list is cached, no events serialized with the
data stream should get through. The cached buffers and events should
be purged when we stop flushing.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
Split the unit tests for rtponviftimestamp and rtponvifparse
elements in separate files.
Setup and cleanup the element and pads in fixures. Make the tests work
with CK_FORK=no as well, by cleaning up the 'buffers' list when needed.
Make unit tests work when run in valgrind by unreffing all buffers,
and by not allocating any payload in RTP buffers. Since we're not
doing anything with the payload part, but we're memcmp-aring the
complete buffer memory, valgrind complained about non-initialized
memory being used.
https://bugzilla.gnome.org/show_bug.cgi?id=757688
The standard does not seem to make any particular explicit not
implicit reference to the signedness of durations, and the code
does not rely on such, nor on the negativity of the -1 value
that's used as a placeholder when a duration property is not
present in the XML.
https://bugzilla.gnome.org/show_bug.cgi?id=750847
According to the standard:
"SegmentBase, SegmentTemplate and SegmentList shall inherit
attributes and elements from the same element on a higher level.
If the same attribute or element is present on both levels,
the one on the lower level shall take precedence over the one
on the higher level."
gst_mpdparser_parse_segment_list_node will now discard any inherited
segment URLs if the parsed element defines some too.
https://bugzilla.gnome.org/show_bug.cgi?id=751832
Add the various tokens/strings for the differnet texture types (2D, rect, oes)
Changes the GLmemory api to include the GstGLTextureTarget in all relevant
functions.
Update the relevant caps/templates for 2D only textures.
Created a unit test for dashdemux. It relies on a fake SOUP HTTP src plugin
that will feed data to dashdemux. The test controls the data to be
generated and checks the correct data was received for each expected
stream.
https://bugzilla.gnome.org/show_bug.cgi?id=756322
If MPD@suggestedPresentationDelay is not present in the manifest,
dashdemux selects the fragment closest to the most recently generated
fragment. This causes a playback issue because this choice does not allow
the DASH client to build up any buffer of downloaded fragments without
pausing playback. This is because by definition new fragments appear on
the server in real-time (e.g. if segment duration is 4 seconds, a new
fragment will appear on the server every 4 seconds). If the starting
playback position was n*segmentDuration seconds behind "now", the DASH
client could download up to 'n' fragments faster than realtime before it
reached the point where it needed to wait for fragments to appear on the
server.
The MPD@suggestedPresentationDelay attribute allows a content publisher
to provide a suggested starting position that is behind the current
"live" position.
If the MPD@suggestedPresentationDelay attribute is not present, provide
a suitable default value as a property of the dashdemux element. To
allow the default presentation delay to be specified either using
fragments or seconds, the property is a string that contains a number
and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
Corrected the parsing of a segment template string.
Added unit tests to test the segment template parsing.
All reported problems are now correctly handled.
https://bugzilla.gnome.org/show_bug.cgi?id=751735
When building the media segment list using a SegmentList node, the
gst_mpd_client_setup_representation function will iterate through the
list of S nodes and will expect to find a matching SegmentUrl node. If
one does not exist, the code made an illegal memory access.
https://bugzilla.gnome.org/show_bug.cgi?id=752496
One may not have an GstGLContext available or current in the thread where one
would need to update the shader. Support this by signalling create-shader
whenever the one-shot 'update-shader' is set to TRUE.
Implemented with videotestsrc ! glshader ! glupload ! gtkglsink
Errors on an invalid shader compilation are ignored however any error
provided by the glsl compiler is printed to stdout.
A GstGLShader is now simply a collection of stages that are
compiled and linked together into a program. The uniform/attribute
interface has remained the same.
When g_option_context_parse fails, context and error variables are not getting free'd
which results in memory leaks. Free'ing the same.
And replacing g_error_free with g_clear_error, which checks if the error being passed
is not NULL and sets the variable to NULL on free'ing.
https://bugzilla.gnome.org/show_bug.cgi?id=753854
While creating caps in audiointerleave tests, bitmask is being set as 0x9
This is resulting in segmentation fault. Fix the same by typecasting to guint64
https://bugzilla.gnome.org/show_bug.cgi?id=755840
The obscured check in compositor was using the dimensions of the pad to clamp
the h/w of the pad instead of the output resolution, and was doing an incorrect
calculation to do so. Fix that by simplifying the whole calculation by using
corner coordinates. Also add a test for this bug which fell through the cracks,
and just skip all the obscured tests if the pad's alpha is 0.0.
https://bugzilla.gnome.org/show_bug.cgi?id=754107
The test_playlist_with_doubles_duration() test fails on some platforms
due to rounding errors that occur when m3u8.c converts from the floating
point value in the HLS manifest to a GstClockTime.
Using assert_equals_float() fixes this because this function handles
the rounding error issues by accepting almost equal.
https://bugzilla.gnome.org/show_bug.cgi?id=753881
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
Instead of checking for the gstreamer-video-1.0 package is installed,
just assume it is since we already check for the -base dependency.
With this replace the GST_VIDEO_* variables in makefiles and directly
link with libgstvideo.
https://bugzilla.gnome.org/show_bug.cgi?id=753820
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.
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
The variables to store face values are only needed if they will be used to
control the volume. Which isn't the default to avoid potentially being very
loud accidentally. Only create variables when needed.
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
gst_gl_memory_setup_wrapped() now takes a destroy notify function. This
destroy notify is called to track the memory life time, hence will
notify each time a memory get destroyed. This test check that the
callback count is correct.
We need to sync the pad values before taking the aggregator and pad locks
otherwise the element will just deadlock if there's any property changes
scheduled using GstController since that involves taking the aggregator and pad
locks.
Also add a test for this.
https://bugzilla.gnome.org/show_bug.cgi?id=749574
They require to get_proc_address some functions through the
platform specific {glX,egl}GetProcAddress rather than the default
GL library symbol lookup.
The previous approach of traversing the other_context weak ref tree was
1. Less performant
2. Incorrect for context destruction removing a link in the tree
Example of 2:
c1 = context_create (NULL)
c2 = context_create (c1)
c3 = context_create (c2)
context_can_share (c1, c3) == TRUE
context_destroy (c2)
unref (c2)
context_can_share (c1, c3) returns FALSE when it should be TRUE!
This does not remove the restriction that context sharedness can only
be tracked between GstGLContext's.
Very much in the same spirit as the Gtk GL sink
Two things are provided
1. A QQuickItem subclass that renders out RGBA filled GstGLMemory
buffers that is instantiated from qml.
2. A sink element that will push buffers into (1)
To use
1. Declare the GstGLVideoItem in qml with an appropriate
objectName property set.
2. Get the aforementioned GstGLVideoItem from qml using something like
QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
QObject *rootObject = engine.rootObjects().first();
QQuickItem *videoItem = rootObject->findChild<QQuickItem *> ("videoItem");
3. Set the videoItem on the sink
https://bugzilla.gnome.org/show_bug.cgi?id=752185
Added unit tests for all functions. Code coverage:
Overall coverage rate:
lines......: 83.8% (1941 of 2316 lines)
functions..: 100.0% (141 of 141 functions)
