We don't want to reset the muxer, otherwise the continuity counter will
reset after each segment and some software gets confused. We want to
create a continuous stream.
https://bugzilla.gnome.org/show_bug.cgi?id=794816
The AVERAGE-BANDWIDTH attribute in the EXT-X-STREAM-INF tag represents
the average segment bit rate of the Variant Stream, while the BANDWIDTH
attribute represents the peak segment bit rate of the Variant Stream.
(https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.4.2)
Using the average bit rate instead of the peak bit rate for variant switching
is more efficient and appropriate. Sometimes due to VBR encoding,
the BANDWIDTH may represent a value way above the average bit rate,
which could result to players not switching to that variant stream
although network bandwidth is sufficiently available.
https://bugzilla.gnome.org/show_bug.cgi?id=790821
It is legal for a stream to reuse segments (marking discontinuities as
needed). Uplynk delivers such playlists for their placeholder loops.
Leave the URI scanning in place for playlists which have no
EXT-X-MEDIA-SEQUENCE tag. This should be harmless since the spec
requires these playlists to not be missing segments (RFC8216 6.2.2),
so we should be always matching on the first segment.
https://bugzilla.gnome.org/show_bug.cgi?id=788417
The function was basically one big if-else. Move the branch to the
one caller.
Currently, it's never called with previous_files == NULL. Assert that
this continues.
https://bugzilla.gnome.org/show_bug.cgi?id=788417
This embeds the muxer inside the sink and accepts elementary streams
while the old HLS sink required the muxer outside. Apart from that the
interface is the same as before.
Currently only mpegtsmux is supported, but support for other muxers is
just a matter of adding a property.
The advantage of the new sink is that it reduces complexity a lot and
properly handles pre-encoded streams with appropriately spaced
keyframes.
https://bugzilla.gnome.org/show_bug.cgi?id=781496
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
The PCR_flag and PCR value is in adaptation_field, not in payload.
The MSB of adaptation_field_control is used as whether adaptation_
field is exist or not.
For the case(PCR in only adaptation_field without payload), we modify
checking condition about adaptation_field_control field.
https://bugzilla.gnome.org/show_bug.cgi?id=778731
For duration queries on live streams, adaptivedemux ignores the query.
The problem then is that the query is answered by the downstream
qtdemux element, with the duration of the currently passing fragment.
This commit changes the behaviour of adaptivedemux to answer the duration
queries for live streams, returning GST_CLOCK_TIME_NONE.
https://bugzilla.gnome.org/show_bug.cgi?id=753879
hls live starts playback from the allowed latest fragment,
but its "sequence position" is set to zero, and so stream
time is also set to zero.
This does not make sense, because hls live allows seeking to past position,
and it's negative stream time from downstream element's point of view.
Note that, allowed seekable range (and seeking query) is
from the first fragment of playlist to the allowed latest fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=777682
HLS spec 6.3.3 is saying that
"the client SHOULD NOT choose a segment which starts less than
three target durations from the end of the Playlist file."
To ensure above statement, the third fragment from the end of playlist
should be excluded from seekable range and also from available starting fragment.
(i.e., the fourth fragment from end of playlist is the starting fragment).
https://bugzilla.gnome.org/show_bug.cgi?id=777682
During live playback, the first fragment in a updated
playlist can be advanced from that of startup playlist.
Meanwhile, since hlsdemux finds target seek position
by just accumulating fragment's duration, the base should
be adjusted to the updated first fragment's timestamp.
https://bugzilla.gnome.org/show_bug.cgi?id=777682
Without failing, we would play back random parts of the stream which is
arguably a worse user experience, and failing is also recommended by the
spec here.
And also handle live streams without any media sequence numbers at all
properly, that is, make sure the sequence numbers are increasing instead
of starting again at 0 every time.
https://bugzilla.gnome.org/show_bug.cgi?id=775665
They often don't only contain the PCR information but also other
metadata, like title. Give this information to the pipeline.
Also strip the tags from the stream as we a) already parsed them now and
b) decoders don't like these tags to happen in the middle of the stream
(i.e. the start of each fragment) and tagdemux only can strip them off
the beginning and end.
When one is only updating the "stop" position (i.e. non-flushing seek,
with GST_SEEK_TYPE_NONE on the "start" (or stop in reverse) position),
we only need to store those values instead of moving the current position.
https://bugzilla.gnome.org/show_bug.cgi?id=775127
If the playlist does not contain any iframe variants then
demux->master->iframe_variants is NULL. If the previous variant is an
iframe variant then there is at least one iframe variant and
demux->master->iframe_variants->data can be safely used.
https://bugzilla.gnome.org/show_bug.cgi?id=773635
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.
