Parsing SIDX box was allowed even if "indexRange" attribute does not appear
for On-Demand profile. However, actual seeking using SIDX index did not happen
since download loop keep working on.
To use SIDX index in that case, demux should try it in the next download loop.
https://bugzilla.gnome.org/show_bug.cgi?id=777394
sidx has "first_offset" syntax which represents the distance in bytes
from anchor point to media fragment. If present, we should adjust
sidx_base_offset.
https://bugzilla.gnome.org/show_bug.cgi?id=776431
Previous patch allows sidx box parsing from incoming buffers.
Since the incoming buffer boundary might be over sidx box,
there can be remaining buffer in isobmff parser adapter.
https://bugzilla.gnome.org/show_bug.cgi?id=776352
The way how strchr() was called here, it could easily read after the end
of the string. Use g_ascii_isspace() instead.
Detected by asan in the unit test.
We set it to TRUE here, but later we set it to TRUE again anyway if the
parsing actually succeeded at this point. Let's keep the second one.
CID 1374360.
Section 5.3.3 in ISO/IEC 23009-1:2014 defines that invalid references
(e.g., invalide URI or cannot be resolved) specified by "@xlink:href" attribute
shall be removed. That means, we should play it without error,
and just ignore the corresponding element.
It's similar to "urn:mpeg:dash:resolve-to-zero:2013".
https://bugzilla.gnome.org/show_bug.cgi?id=774463
External xml could have empty, one or multiple top-level "Period" elements.
Because xml parser cannot parse the multiple top-level elements
(i.e., no root element), we need to wrap a xml in order to make root element.
See also ISO/IEC 23009-1:2014 5.3.2.2
https://bugzilla.gnome.org/show_bug.cgi?id=774357
PlayReady being the one of the few DRM formats encoding its data with
base64 it was not consistent to have a special case for this. So the
base64 decoding operation now needs to be done by the protection event
consumer, if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=774112
With MSVC, this gives the following warning:
warning C4305: 'function': truncation from 'double' to 'gfloat'
Apparently, MSVC does not figure out what type to use for constants
based on the assignment. This warning is very spammy, so let's try to
fix it.
And scale the bitrate with the absolute rate (if it's bigger than 1.0) to get
to the real bitrate due to faster playback.
This allowed in my tests to play a stream with 10x speed without buffering as
the lowest bitrate is chosen, instead of staying/selecting the highest bitrate
and then buffering all the time.
It was previously disabled for not very well specified reasons, which seem to
be not valid anymore nowadays.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Matej Knopp <matej.knopp@gmail.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
We don't have to do yet another additional request but can just download the
data directly.
Also unify the key-unit only mode buffer pushing and extract it into its own
function now that it became more complicated.
https://bugzilla.gnome.org/show_bug.cgi?id=741104
We need to mark every first buffer of a key unit as discont, and also every
first buffer of a moov and moof. This ensures that qtdemux takes note of our
buffer offsets for each of those buffers instead of keeping track of them
itself from the first buffer. We need offsets to be consistent between moof
and mdat
https://bugzilla.gnome.org/show_bug.cgi?id=741104
This reverts commit 947656cfd2.
This makes all dash seeking tests fail. Needs more testing to fully understand
what's going wrong. Revert ok'd by Sebastian
We don't need to call the latter at all as we're definitely in this period and
the segment is selected via the SIDX.
This is especially important when doing SNAP seeks, as otherwise we would
always start from the beginning of the period (usually 0) again.
The gst_dash_demux_get_live_seek_range () function returns a stop value
that is beyond the available range. The functions
gst_mpd_client_check_time_position() and
gst_mpd_client_get_next_segment_availability_end_time() in
gstmpdparser.c include the segment duration when checking if a segment
is available. The gst_dash_demux_get_live_seek_range() function
in gstdashdemux.c ignores the segment duration.
According to the DASH specification, if maxSegmentDuration is not present,
then the maximum Segment duration is the maximum duration of any Segment
documented in the MPD.
https://bugzilla.gnome.org/show_bug.cgi?id=753751
