Otherwise we'll get into an infinite loop here. Now this is still not
correct and will cause a clean error, but at least it won't hang forever
anymore.
meson's configure_file emits only a comment like /* #undef ... */
for values which are unset in the configuration_data. For
gstglconfig.h, this differs from the autotools build where the
preprocessor definitions are always either 0 or 1. So loop over a
list of variables to set to zero as default.
Also sync up the gstglconfig.h.meson file with the additional
macros defined by the autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=781043
Windows aren't always removed in time, and it turns out to be
very, very hard to remove a window in a way that's not racy and
not deadlocky. Since the window itself doesn't leak, freeing
the list on object destruction is enough.
https://bugzilla.gnome.org/show_bug.cgi?id=781018
At the moment that demux is waiting manifest update, the target sequence
of fragment was advanced already. So, checking stream_has_next_fragment()
means looking for the next fragment of target fragment.
This might cause unexpected buffering if each fragment has
large duration and manifest is listing only limited number of fragments.
https://bugzilla.gnome.org/show_bug.cgi?id=780494
For each period, media presentation is the relative to the
period-start time. So SIDX seek position should be target seek
position minus period-start. Also, if presentationTimeOffset
is defined, the value should be compensated
https://bugzilla.gnome.org/show_bug.cgi?id=780397
Significant whitespace in elements that don't have begin/end values
should inherit timing from its parent, or if no its parents have no
timing, from the document's Root Temporal Extent. Currently, such
whitespace is removed, which is not spec-compliant. Fix this by
retaining whitespace in content nodes, and assigning a Root Temporal
Extent of 24 hours to any significant whitespace whose parents have no
associated timing.
https://bugzilla.gnome.org/show_bug.cgi?id=781027
The specified behaviour in TTML when lineHeight is "normal" is different
from the behaviour when a percentage is given. In the former case, the
line height is a percentage (the TTML spec recommends 125%) of the largest
font size that is applied to the spans within the block; in the latter
case, the line height is the given percentage of the font size that is
applied to the block itself.
The code doesn't correctly implement this behaviour; this patch fixes
that.
https://bugzilla.gnome.org/show_bug.cgi?id=780402
In TTML, the height of every line in a block is determined by lineHeight
and fontSize style attributes, and should be the same for each line in
that block, regardless of whether different sized text appears on
different lines. Currently, a single PangoLayout is used to lay out all
the text in a block; however, pango will vary the line height in a
layout depending on the size of text used in each line, which is not
compliant with TTML.
This patch makes ttmlrender lay out the lines in a block itself, rather
than using a PangoLayout to do the work. The code still uses a
PangoLayout to render the text of each element, but the overall layout
of the text in a block is now controlled by ttmlrender itself. By doing
this, ttmlrender is able to ensure that the height of each line in a
block is correct.
https://bugzilla.gnome.org/show_bug.cgi?id=780402
The GstGLFramebufferClass struct is typedeffed in
gstgl_fwd.h, and having a duplicate elsewhere is
breaking the cerbero build on my OSX machine,
even though it seems to be working in CI.
When entering this code path, we know that:
We received EOS on this pad.
We consumed all its buffers.
In any case, we want to replace vaggpad->buffer with NULL,
otherwise we will end up mixing the same buffer twice.
https://bugzilla.gnome.org/show_bug.cgi?id=781037
segsize should be based on latency-time, and must be a multiple of the
frame size. segtotal should be based on buffer-time and segsize.
This prevents errors caused by outputting buffers that are not a
multiple of the frame size, and actually makes the buffer-time and
latency-time properties do what they're supposed to do.
If set, the parent is used to proxy need-context messages from
uridownloader's http source in order to get cookies/headers
from the pipeline.
Based on a patch from Philippe Normand
https://bugzilla.gnome.org/show_bug.cgi?id=726314
When there are more than 64 channels, we don't want to exceed the
bounds of the ordering_map buffer, and in these cases we don't want to
remap at all. Here we avoid doing that.
Based on a patch originally for plugins-good/interleave in
https://bugzilla.gnome.org/show_bug.cgi?id=780331
The element now exposes properties to enable and configure
voice activity detection, and posts "voice-activity" messages
when the return value of stream_has_voice () changes.
https://bugzilla.gnome.org/show_bug.cgi?id=779138
This duplicated property is no longer needed as there is now API to
allow bindings access GST_TYPE_ARRAY (see gst_util_get/set/object_array).
Additionnally, Python has proper overrides which will make this looks
like Python. A 2x2 matrix would be set this way:
element = matrix = Gst.ValueArray(Gst.ValueArray([1.0, -1.0]),
Gst.ValueArray([1.0, -1.0))
Notice that you need to "cast" each arrays to Gst.ValueArray, otherwise
there is an ambiguity between Gst.ValueArray and Gst.ValueList list type.
Fortunatly, Gst.ValueArray implements the Sequence interface, so it can
be indexed like normal python matrix.
A live manifest may have a set (> LookAheadFragmentCount) of fragments
that have already been served and are stored on the server, maybe
indefinitely. Adding the parsed live fragments after the manifest
fragments breaks duration reporting and the seekable range.
Fix by only adding parsed fragments outside the list of fragments which
assumes that the fragment list in the manifest is accurate enough to not
stray too far off what's in the retrieved data.
https://bugzilla.gnome.org/show_bug.cgi?id=779447
