Support video with multiview info in the caps, transform
it to mono anaglyph by default, but allow for configuring
other output modes and handoff to the app via
the draw signal.
https://bugzilla.gnome.org/show_bug.cgi?id=611157
Added some warning messages in gst_mpd_client_setup_streaming to help
debug situations when the function will return FALSE.
Renamed a wrongly spelled variable.
https://bugzilla.gnome.org/show_bug.cgi?id=751149
Corrected some comments in gstmpdparser.h file.
Moved gst_mpd_client_get_adaptation_sets function to be grouped with
other functions from AdaptationSet group
https://bugzilla.gnome.org/show_bug.cgi?id=751149
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
Getting the current viewport and modifying it relatively will produce an
interesting feedback loop during widget resizing. Over a few frames we
will gradually move the viewport a bit until it converged again, adding
unnecessary additional borders at the top and left.
We now know that pool caching can cause renegotiation issues
when an element in the pipeline change from passthrough to not
passthrough. As it's not needed, don't cache existing pools.
https://bugzilla.gnome.org/show_bug.cgi?id=748344
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
If the presentationTimeOffset attribute of a DASH manifest contains
a value that is larger than 2^32, gstmpdparser incorrectly calculates
the stream's presentation time offset. This is due to two bugs:
1: Using gst_mpdparser_get_xml_prop_unsigned_integer rather than
gst_mpdparser_get_xml_prop_unsigned_integer_64 to parse the
attribute
2: gst_mpd_client_setup_representation multiplying the value by
GST_SECOND and then dividing by timescale
https://bugzilla.gnome.org/show_bug.cgi?id=750804
This patch allow going gst-inspect-1.0 on these elements removing
ugly crash that was previously occurring. The method consist of
making the widget creation as lazy as possible. This way we don't
endup doing gtk_init() before the application. We also ref_sink()
the widget, so we don't crash if the parent widget is discarded,
and cleanly error out with GL if the widget has no parent window,
because calling gtk_widget_realized() can only be done if the widget
has been parented to a window).
This reverts commit 4ca3a22b6b.
The connection-speed=0 is used as a special value in the property
of hlsdemux to mean 'automatic' selection, m3u8.c doesn't need
to know about that as it should be as simple as possible.
So this patch hides this automatic selection documented in hlsdemux
into m3u8 logic and I think the gets harder to understand the code.
It also makes the hlsdemux unit tests work again
https://bugzilla.gnome.org/show_bug.cgi?id=749328
This reverts commit 37011e5198.
This change was actually completely unnecessary, the streams in question are
marked as static and are not considered live anyway.
Otherwise we'll only get half of its bits printed on 32 bit architectures.
For this, promote the %d-style format strings to something that accepts
64 bit integers with G_GINT64_MODIFIER.
Using format strings from an untrusted source without validation is
calling for problems, and at least allows to remotely crash your application.
If not worse.
In live situations, it is not uncommon for the current fragment to end
up out of the (updated) play range (lowest/highest sequence). But the next
fragment to play *is* present in the play range.
When advancing, if we can't find the current GstM3U8MediaFile, don't abort
straight away. Instead, look if a GstM3U8MediaFile with the next sequence value
is present, and if so switch to it.
https://bugzilla.gnome.org/show_bug.cgi?id=750028
Previously when compiling GstGL with both GL and GLES2,
GL_RGBA8 was picked from GL/gl.h. But a clash may happen at
runtime when one is selecting GLES2.
gst_gl_internal_format_rgba allows to check at runtime
if it should use GL_RGBA or GL_RGBA8.
The functions to get the next fragment, next fragment timestamp and to advance
to the next fragment need to work differently when stream->segments is NULL.
Use logic similar to that introduced by commit 2105a310 to perform these
functions.
https://bugzilla.gnome.org/show_bug.cgi?id=749684
Previously the VPS unit was detected and all next packets where copied
into the header buffer assuming only SPS and PPS would follow. This is
not always true, also other types of NAL units follow the VPS unit and
where copied to the header buffer. Now the VPS/SPS/PPS are explicitely
detected and copied in the header buffer.
1. Set the sync point after the (possible) upload has occured
2. Wait in the correct GL context (the draw context)
Note: We don't add the GL sync meta to the input buffer as it's not
writable and a copy would be expensive.
Similar to the change with the same name for glimagesink
1. Set the sync point after the (possible) upload has occured
2. Wait in the correct GL context (the draw context)
Note: We don't add the GL sync meta to the input buffer as it's not
writable and a copy would be expensive.
The property level has a minimum value of 0. But when we set the level as 0,
it gets an assertion error. The function icvPyrSegmentation8uC3R returns false
if level is set as 0, since the minimum level cant be 0 and thus results in error.
Hence changing the minimum value to 1.
https://bugzilla.gnome.org/show_bug.cgi?id=749525
