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)
flexelint (http://www.gimpel.com/html/flex.htm) static code analyser
complained about implicit conversions from unsigned to signed, so I added
explicit conversions.
Ideally, the size parameter of gst_mpd_parse function should be unsigned,
but I don't want to change the API.
The duration_to_ms function converts a time specified by year, month, day,
hour, minute, second, millisecond to a millisecond value. Because all the
arguments are positive numbers, the result must also be positive.
This patch changes the returned value from a gint64 to a guint64 type.
Improved dash_mpd unit tests by adding new tests that parse the Period element.
Code coverage reported by lcov for dash/gstmpdparser.c is:
lines......: 43.0% (985 of 2290 lines)
functions..: 47.5% (67 of 141 functions)
According to ISO/IEC 23009-1:2014(E), chapter 5.3.2.1
"The Period extends until the PeriodStart of the next Period, or until
the end of the Media Presentation in the case of the last Period."
This means that a configured value for optional attribute period duration
should be ignored if the next period contains a start attribute or it is
the last period and the MPD contains a mediaPresentationDuration attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=750797
The gst_mpdparser_get_rep_idx_with_max_bandwidth function assumes
representations are ordered by bandwidth and incorrectly returns the
first one when wanting the one with minimum bandwidth.
Corrected gst_mpdparser_get_rep_idx_with_max_bandwidth function to get the
correct representation in case max_bandwidth parameter is 0.
https://bugzilla.gnome.org/show_bug.cgi?id=751153
Added a check for a_node->ns before accessing a_node->ns->href in
gst_mpdparser_get_xml_node_namespace. This could happen if the xml
is missing the default namespace.
https://bugzilla.gnome.org/show_bug.cgi?id=750866
An example app that takes video URIs as command line arguments and switches
between them seamlessly one after the other using compositor and audiomixer.
Both audio-video and video-only media files are valid inputs, but mixing files
of both types in a single invocation is cumbersome to support, and hence does
not work. The example attempts to keep the audio stream moving along perfectly,
and duplicates video frames where necessary to cover gaps in the video
timestamps using the 'ignore-eos' videoaggregator pad property.
Ensuring seamless (and mostly-glitch-free) switching is harder than it sounds,
and hence the example contains plenty of pad probes and running time
calculations to make things work.
The GPtrArray play_queue contains items that are being played back, have been
prepared for playback, and will be played back in the future. The queue itself
is mutable besides the first two items (playing and prepared). The item that has
been prepared should not be edited or removed since it has been prepared in
advance to be activated immediately on the current item's EOS.
The example also has support for switching to the next item in the queue
prematurely; see the --switch-after/-s flag to the application.
Note: the output video is hard-coded at 1280x720, and input video is scaled as
needed to fit this size. Set OUTPUT_VIDEO_WIDTH/HEIGHT to change this.
https://bugzilla.gnome.org/show_bug.cgi?id=748947
When the 'ignore-eos' property is set on a pad, compositor will keep resending
the last buffer on the pad till the pad is unlinked. We count the buffers
received on appsink, and if it's more than the buffers sent by videotestsrc, the
test passes.
g_object_get() returns a ref, gtk_container_add() only ref_sink().
That mean we still need to unref afterward. This leak was hiding
a reference bug previously present.
Lets not cram everything into a single test - this would render the test name
useless for quick diagnosis. Having separate tests for the optional feature is
also verifying the behaviour when the feature is off.
Rather than one of the input pad video info's.
The test checking this was not constraining the output frame size
to ensure that the out of frame stream was not being displayed.
We verify that all the buffers on an obscured sinkpad are skipped by overriding
the map() function in the GstVideoMeta of the buffers to set a variable when
called. We also test that the buffers do get mapped when they're not obscured.
Blame^WCredit for the GstVideoMeta map() idea goes to Tim.
https://bugzilla.gnome.org/show_bug.cgi?id=746147
If 95% of the code of an example app consists of GObject
code, maybe that's defeating the point a little. So just
remove a lot of that and trim down the example to the
absolute minimum. Also removes the last remaining GPL3
licensed code in -bad.
GstPhotography enables new paths in wrappercamerabinsrc that allows
the source to be notified about the capture caps and provide an
alternative caps if desired bypassing the negotiation (this doesn't
seem like a good idea these days). To make sure it keeps working
until we remove it from the API in favor of standard caps negotiation
features this test was added.
It adds 3 extra tests with a simple test source that will:
1) Test that capturing with ANY caps work
2) Test that capturing with a fixed caps work
3) Test that capturing with a fixed caps and having the source
pick a different resolution from GstPhotography API works
by having wrappercamerabinsrc crop the capture to the final
requested dimensions
A bitmask is 64 bits, but integer immediates are passed as int
in varargs, which happen to be 32 bit with high probability.
This triggered a valgrind jump-relies-on-uninitalized-value
report well away from the site, since it doesn't trigger on
stack accesses, and there must have been enough zeroes to stop
g_object_set at the right place.
The first output MPEG-TS packet that corresponds to a video input
buffer which had the delta flag cleared (i.e. was a keyframe)
should have the delta flag cleared as well.
This is needed e.g. by tcpserversink in order to keep track
of the last keyframe and be able to burst data to newly-
connected clients.
https://bugzilla.gnome.org/show_bug.cgi?id=706872
This reverts commit 1c77d12ce8.
"interlaced" in the caps don't mean the same thing as the SOF2 marker in the
JPEG format. This test passes because of broken behaviour.
The flush stop could have happened between the source trying
to push the segment event and the buffer, this would cause a warning.
Prevent that by taking the source's stream lock while flushing.
https://bugzilla.gnome.org/show_bug.cgi?id=742684
With the current audiomixer, the input caps need to be the same,
otherwise there is an unavoidable race in the caps negotiation. So
enforce that using capsfilters
https://bugzilla.gnome.org/show_bug.cgi?id=742684
Get rid of now-useless packetizer struct and just
call internal functions directly. Also remove
version property which is now defunct, not least
because we create the packetizer with the
version in the init function before a version
can be set.
When this is TRUE, we really have to produce output. This happens
in live mixing mode when we have to output something for the current
time, no matter if we have enough input or not.
Using NSApp directly seems to confuse something, as the compiler
was expecting an id<NSFileManagerDelegate>. Switched to using
[NSApplication sharedApplication], and specified the delegate
protocol on the window class as well.
Similar to https://bugzilla.gnome.org/show_bug.cgi?id=738740
The GPL3 license header was copy'n'pasted from a
neighbouring source file by mistake, the original
code was not GPL3 licensed, but fell under the
default GStreamer license, which is LGPLv2+.
https://bugzilla.gnome.org/show_bug.cgi?id=685655
Until gcc and GNUStep properly support Objective-C blocks and other
"new" features of Objective-C we can't properly support them without
making the code much more ugly.
https://bugzilla.gnome.org/show_bug.cgi?id=739152
Serves no purpose, is not even hooked up to the
build system, has hard coded file names and paths,
and can easily be replaced with a gst-launch line.
https://bugzilla.gnome.org/show_bug.cgi?id=739844
We need to pass the X11 display to GstGL or else it will
use its own X11 Display pointer, and the GL Context won't get shared
correctly on newer X servers
In file included from /home/thiagoss/gst/head/gstreamer/gst/gst.h:54:0,
from /home/thiagoss/gst/head/gstreamer/libs/gst/check/gstcheck.h:34,
from elements/hlsdemux_m3u8.c:27:
../../ext/hls/gstfragmented.h:8:28: error: redundant redeclaration of ‘fragmented_debug’ [-Werror=redundant-decls]
GST_DEBUG_CATEGORY_EXTERN (fragmented_debug);
Move the definition of the category to after the declaration.
Ported from https://github.com/ylatuya/gst-plugins-bad
This still has some unit tests for alternative renditions and
seeking, which are commented out for the time being until we
support them properly.
1. glcontextid function is replaced by gstreamer gst_gl_context_new_wrapped .
2. call gst_init before gst_gl_display_new , seems gst_gl_display_new depends
on gst_allocator_register , which only worked after gst_init called
3. flush gstreamer OpenGL context before using shared texture, fix
flicker problem.
https://bugzilla.gnome.org/show_bug.cgi?id=735566
Use the sticky events to compose the streamheader as they are the
ones that are persisted to config new pads linked. Instead of storing
them ourselves rely on the pad storage that already orders it for us
https://bugzilla.gnome.org/show_bug.cgi?id=732596
Check that end_of_seq() [EOSEQ] and end_of_stream [EOS] NAL units
are correctly parsed and the reported NAL unit size yields 1 byte,
i.e. the only NalHeaderBytes in there.
https://bugzilla.gnome.org/show_bug.cgi?id=732553
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
