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.
After the check in line 1,111, media->uri can't be NULL. So the two checks
for GST_HLS_MEDIA_TYPE_CLOSED_CAPTIONS are the same, removing the redundant
one which goes to cc_unsupported.
CID 1364752
Create an output stream for each media when alternate renditions
are present. Update the manifests for all those streams, and
make sure that typefinding is still done for files smaller than 2KB
such as small WebVTT files.
When fetching a byte-region from a server resource,
adjust the downstream buffer offsets so that downstream
doesn't know. This is because id3demux insists on the
first offset being 0. Later we might strip ID3 headers
entirely and this will be unneeded.
Modify playlist updating to track information across updates
better, although still hackish.
When connection_speed == 0, choose the default variant
not the first one in the (now sorted) variant list, as that
will have the lowest bitrate.
Make M3U8 and GstM3U8MediaFile refcounted. The contents
of it and GstM3U8MediaFile are pretty much immutable
already, but if we make it refcounted we can just
return a ref to the media file from _get_next_fragment()
instead of copying over all fields one-by-one, and then
copying them all into the adaptive stream structure fields again.
Move state from client into m3u8 structure. This will
be useful later when we'll have multiple media playlists
being streamed at the same time, as will be the case with
alternative renditions.
This has the downside that we need to copy over some
state when we switch between variant streams.
The GstM3U8Client structure is gone, and main/current
lists are not directly in hlsdemux. hlsdemux had as
many CLIENT_LOCK/UNLOCK as the m3u8 code anyway...
Don't clear decryption state immediately after
initialising it in the start_fragment. Don't clear
the state of all streams when we want to only clear
the current stream.
https://bugzilla.gnome.org//show_bug.cgi?id=768757
Add demuxer instance-wide decryption key cache. The current and
last key url are per-stream, so make a shared cache. Move the
decryption handling into the stream object, and use the shared
cache for the keys.
Prepare hlsdemux for more than one single stream. Currently hlsdemux
assumes there'll only ever be one stream and most of the stream-specific
state is actually in the hlsdemux structure. Add a stream subclass
instead and move some stream-specific members there instead.
When switching fragments we don't want to keep any data around from the last
one, and also forget about all data when doing flushing seeks or selecting new
bitrates.
https://bugzilla.gnome.org/show_bug.cgi?id=764684
Handling the ghostpad and its internal pad was causing more issues
than helping because of their coupled activation/deactivation
actions.
As we have to install custom chain,event and query functions it is
better to use a floating sink pad internally in the demuxer and just
use those pad functions to push through a standard pad in the demuxer
https://bugzilla.gnome.org/show_bug.cgi?id=757951
Properly handle snap flags during reverse seeking. In this case
the before/after are also reversed, so handle those as such.
For example: with a sequence of 1s fragments:
|-- 0 --|-- 1 --|-- 2 --|-- 3 --|
If you seek to 1.5s it is inside fragment 1. With reverse and
snap-before: should play from the end of fragment 1
snap-after: should play from the end of fragment 0
The URI attribute from the EXT-X-KEY tag and the URI attribute from the
EXT-X-I-FRAMES-ONLY tag are both quoted-string attibutes that have their
quotation marks removed during parsing. The CODECS attribute of the
EXT-X-STREAM-INF is also a quoted-string attribute, but this attribute
was not being un-quoted.
This commit changes the parser to always unquote all quoted-string
attributes and adjusts the unit tests to this new bevahiour for the
CODECS attribute.
An additional test is added to check that parsing of all of the fields
in the EXT-X-STREAM tag is correct, including those that contain comma
characters.
https://bugzilla.gnome.org/show_bug.cgi?id=758384
Clear error as soon as we determine that the download failed,
otherwise there are code paths where we might return without
clearing it ever, which would leak the GError then. Also, we
can pass a NULL GError pointer to _fetch_uri(), so just do that
instead of passing one that we're going to just free again
right away anyway.
Setting the seek flags to GST_SEEK_FLAG_SNAP_* will change the seek
target time to a segment boundary.
Based on original work by Ben Willers <bwillers@digisoft.tv>.
https://bugzilla.gnome.org/show_bug.cgi?id=759108
As HLS does not provide any way of knowing the server's clock, and we do
buffering of "live" streams, at some point we will fall behind the server in
many cases and would have to advance to a fragment that is not in the playlist
anymore.
Previously we would've just resynced to the next oldest fragment that is still
there, but this causes problems as from this point onwards we would always
fall off the playlist again all the time.
Instead we now resync and move to the 3rd newest fragment like we would do
when starting playback of a live stream.
https://bugzilla.gnome.org/show_bug.cgi?id=758987
If connection speed is set, playlist according
to connection speed is selected as current playlist.
Problem is that the current variant of main playlist still
points to previously set variant.
If previously set variant doesn't correspond to current
playlist, then it causes unnecessary change of playlist
to the same playlist after first fragment is downloaded,
because of not updated current variant.
To fix this, we need to make sure that current variant
of main playlist corresponds to the current playlist
https://bugzilla.gnome.org/show_bug.cgi?id=758946
Don't jump backward to 3 files from the end of the playlist
when switching variants - it just means we downloaded
fragments fast and caught up to the end of the playlist.
Disable that by treating a variant switch as a playlist
update, not a restart due to a seek or so.
If the stream is discont, we must provide a timestamp in any case. Elements
like tsdemux are not going to output anything if we give a NONE timestamp
after a discont.
Also marking a stream as discont if a playlist change was not successful would
lead to the above situation, but in that case we are not required at all to
mark the stream discont as we're still at the old playlist.
If a (master) playlist contains a variant list entry without a
URI then during parsing of the next variant list entry we are
a) leaking the entry we're currently parsing (new_list), and
b) free'ing the pointer to the previous list entry (list) without
updating the pointer.
Hence when then adding the URI for the latest parsed entry, incorrect
information is stored, as the information is used from 'list' which
is not valid memory anymore, also leading to crashes.
Fix this by correctly storing the new variant list entry pointer
as needed.
https://bugzilla.gnome.org/show_bug.cgi?id=756861
Nicer to read, two lines of code less, and also the callback
function should've been a GCompareFunc that returns a gint
and not a boolean (it did work correctly, was just confusing).
In order to ensure the sequence_position will always be consistently updated,
store the current file duration.
This way, when we advance, we can always increment the position based on what
was previously outputted.
https://bugzilla.gnome.org/show_bug.cgi?id=752132
Allows playlists that are missing the mediasequence information to
be correctly parsed. If the playlist was updated without reseting
the mediasequence it would constantly increase over subsequent updates,
leading to issues during playback.
For live streams, we want to make sure there's a certain distance
between the sequence to play and the last (earliest) fragment.
The problem is that it assumes there are at least 3 fragments in
the playlist, which might not always be the case (like in the case
of a server restarting and gradually adding fragments).
In order to avoid ending up with negative sequence numbers (which
will just loop forever), limit the new target sequence number to
the highest of:
* either the first sequence number of the playlist (fallback)
* or 3 fragments from the last one (standard behaviour)
Move the TAG defines directly into the code, not sure what
their purposes is, these are printf format strings so having
them directly as literals in the code where they're used
makes the code easier to follow.
Remove playlist_str GString variable from GstM3U8Playlist struct,
since it's only used temporarily in playlist_render(). Might just
as well keep it local then.
Some live streams (eg youtube) don't remove fragments in order to allow
seeking back in time (live + vod).
When gst_m3u8_client_has_next_fragment is called, we are getting wrong fragment
because current_file points in first file of the fragments list resulting in
watching the stream from the beginning again.
This patch sets current_file to nth fragment for live streams, then on
gst_m3u8_client_has_next_fragment will keep up with the live stream.
https://bugzilla.gnome.org/show_bug.cgi?id=753344
