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
When all fragments have already been downloaded on a live stream
dashdemux would busy loop as the default implementation of
has_next_fragment would return TRUE. Implement it to correctly
signal if adaptivedemux should wait for the manifest update before
trying to get new fragments.
When updating the manifest the timestamps on it might have changed a little
due to rounding and timescale conversions. If the change makes the timestamp
of the current segment to go up it makes dashdemux reposition to the previous
one causing one extra unnecessary download.
So when repositioning add an extra 10 microseconds to cover for that rounding
issues and increase the chance of falling in the same segment.
Additionally, also improve the time used when the client is already after the
last segment. Instead of using the last segment starting timestamp use the
final timestamp to make it reposition to the next one and not to the one that
has already been downloaded.
These functions of directly getting and setting segment indexes
are no longer useful as now we need 2 indexes: repeat and segment
index.
The only operations needed are advance_segment, going back to the
first one or seeking for a timestamp.
Segments are now stored with their repeat counts instead of spanding
them to multiple segments. This caused advancing to the next segment
using a single index to have to iterate over the whole list every time.
This commit addresses this by storing both the segment index as well
as the repeat index and makes advancing to next segment just an
increment of the repeat or the segment index.
Use a single segment to represent it internally to avoid using too
much memory. This has the drawback of issuing a linear search to
find the correct segment to play but this can be fixed by using
binary searches or caching the current position and just looking
for the next one.
https://bugzilla.gnome.org/show_bug.cgi?id=748369
