| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The error: location takes care of freeing new_representation
CID #1405027
|
| |
|
|
|
|
|
|
| |
SegmentTemplate nodes
https://bugzilla.gnome.org/show_bug.cgi?id=778237
|
|
|
|
|
|
|
|
| |
in keyunit-only trick mode
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.
|
|
|
|
|
|
|
| |
Spec "5.3.5 Representation" is saying that
id and bandwidth attributes are mandatory fields.
https://bugzilla.gnome.org/show_bug.cgi?id=780569
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Without this, subtitles will stop after seeking.
https://bugzilla.gnome.org/show_bug.cgi?id=780897
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
|
|
|
| |
Include a reference to the GstSubtitleStyleSet of the represented block
and a string containing the concatenated text from all elements.
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780402
|
|
|
|
|
| |
Meson was creating libgstmplex2.so which didn't match the plugin name
'mplex'.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780642
|
|
|
|
| |
s/enveloppe/envelope
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
This fixes build failure in mplex and mpeg2enc plugins and most likely
in kate plugin (untested).
|
| |
|
|
|
|
|
|
| |
fragment, start with the previous one instead
There's no point to start downloading a fragment just to output 1ns.
|
| |
|
|
|
|
| |
We know which number is bigger.
|
|
|
|
| |
be the exact segment position
|
|
|
|
|
|
| |
calculating it again
It does the exact same calculations.
|
|
|
|
|
| |
Also go out of the segment searching loop once segment->start > ts.
We're not going to find any earlier segment anymore.
|
|
|
|
|
|
|
|
| |
Instead of just going to the first or last fragment, report if we're
going outside the index. This should never happen unless there's a bug
or the stream is broken.
Allow some possibility for inaccuracies here though.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=776140
|
|
|
|
|
|
| |
EXT-X-DISCONTINUITY tag should have no trailing ":" character
https://bugzilla.gnome.org/show_bug.cgi?id=780179
|
|
|
|
|
|
| |
To fix deadlock during live m3u8 update
https://bugzilla.gnome.org/show_bug.cgi?id=780180
|
|
|
|
|
|
| |
segment
https://bugzilla.gnome.org/show_bug.cgi?id=780108
|
|
|
|
|
|
|
| |
Remove assertions and replace, where necessary, with code that handles
the error cases.
https://bugzilla.gnome.org/show_bug.cgi?id=776436
|
|
|
|
|
|
|
| |
disable the SIDX usage for this segment
The SIDX apparently does not contain information about the current
segment, so better stop using it instead of using incorrect values.
|
|
|
|
|
|
|
|
| |
representations
There is no guarantee that the index positions are the same between
representations, and assuming this easily causes us to get into invalid
index positions.
|
|
|
|
|
| |
And especially don't keep entry count and index around, we have no
entries anymore after clearing.
|
|
|
|
|
|
|
| |
Some of streams such as below have tailing boxes at the end of subfragment.
http://dash.akamaized.net/dash264/TestCases/1a/netflix/exMPD_BIP_TC1.mpd
https://bugzilla.gnome.org/show_bug.cgi?id=776200
|
|
|
|
|
|
|
|
|
| |
If a MPD is On-Demand profile and no index described, demux will terminate
download loop after parsing inband SIDX with flow return custom-success.
At this moment, SIDX index is excat target position, but finish_fragment()
might cause re-advancing subfragment depending on MPD structure.
https://bugzilla.gnome.org/show_bug.cgi?id=776200
|
|
|
|
|
|
|
|
| |
SIDX's base offset (i.e., byte offset of SIDX + sidx.first_offset)
mostly vary as per fragment. Also, target SIDX index must be zero for the
new fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=776200
|
|
|
|
|
|
|
|
|
| |
Try to find fragment using MPD first, then do refinement to find
target subframgnet using SIDX if possible. Note that, if target fragment
was moved from the previously activated one, we should assume that
the last SIDX is invalid for new fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=776200
|
|
|
|
|
|
|
| |
If target seek position is outside of the range of sidx entries,
binary search returns NULL pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=776200
|
|
|
|
|
|
| |
entries array
Better crash cleanly here than reading some random numbers from memory.
|