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 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
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.
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.
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
SIDX based playback is not restricted to SegmentBase, but it possible
with SegmentList/SegmentTemplate. In the latter case, each fragment
has its own SIDX box and might be subdivided into subfragment.
So, demux should not assume that the end of subfragment is the end
of stream. Moreover, should try advance subfragment only if there
are remaining subfragments.
With additional fixes by Sebastian Dröge <sebastian@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776200
All code interacting with Objective-C objects should now use Automated
Reference Counting rather than manual memory management or Garbage
Collection. Because ARC prohibits C-structs from containing
references to Objective-C objects, all such fields are now typed
'gpointer'. Setting and gettings Objective-C fields on such a
struct now uses explicit __bridge_* calls to tell ARC about
object lifetimes.
https://bugzilla.gnome.org/show_bug.cgi?id=777847
hlsdemux tries to find type if given buffer size is large enought to
find type (currently the threshold is 2KB), or EOS in some cases.
However, since there can be small byte fragments such as WebVTT,
demux should try to find type at the end of a fragment
https://bugzilla.gnome.org/show_bug.cgi?id=779011
This appears to be the internal limit of voaacenc, higher
bitrates will be ignored and 128 kbps output will be produced
instead. Therefore, we might just as well limit the allowed
property values, so that people who try to set higher bitrates
get a big fat warning instead of silently a much lower bitrate.
