| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
For not being duplicated here it was being freed when the manifest was
being destroyed and a second time when the buffer was being destroyed.
|
|
|
|
|
|
|
| |
The only plugins remaining are those that haven't been ported to Meson
yet, and msdk. Also, the tests are still automagic.
https://bugzilla.gnome.org/show_bug.cgi?id=795107
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=794568
|
|
|
|
| |
Nothing guarantees the manifest is valid and will return a root node
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=787736
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=777825
|
| |
|
|
|
|
|
| |
Static and dynamic plugins now have the same interface. The standard
--enable-static/--enable-shared toggle are sufficient.
|
|
|
|
|
|
|
|
| |
../subprojects/gst-plugins-bad/ext/smoothstreaming/gstmssdemux.c: In function ‘gst_mss_demux_requires_periodical_playlist_update’:
../subprojects/gst-plugins-bad/ext/smoothstreaming/gstmssdemux.c:729:16: error: unused variable ‘mssdemux’ [-Werror=unused-variable]
GstMssDemux *mssdemux = GST_MSS_DEMUX_CAST (demux);
^~~~~~~~
cc1: all warnings being treated as errors
|
|
|
|
|
|
|
| |
Without this, for streams where the content is stored indefinitely and
can be seeked on, the duration would never increase when in paused or,
until we reached near the end of the currently advertised stream (where
the internal fragment parser would see descriptions of new fragments).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Completely disabling duration reporting with live streams is not cool.
This reverts commit e1b68d9a65ba512a52c3a2b298fa830a445eb451.
https://bugzilla.gnome.org/show_bug.cgi?id=753879
|
|
|
|
|
| |
Use the flags defined by configure script instead of always disabling
static plugins.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Just a matter of reordering a g_free() /after/ cleaning out all the
members.
CID 1396746
|
|
|
|
|
| |
Follow-up of 73721ad4e9e2d32e1c8b6a3b4aaa98401530e58a.
Forgot to add the fragment parser in the meson build file.
|
|
|
|
|
|
|
|
|
|
|
| |
When a MSS server hosts a live stream the fragments listed in the
manifest usually don't have accurate timestamps and duration, except
for the first fragment, which additionally stores timing information
for the few upcoming fragments. In this scenario it is useless to
periodically fetch and update the manifest and the fragments list can
be incrementally built by parsing the first/current fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=755036
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
in the manifest
Provides a more accurate duration for live streams that may be minutes
or hours in front of the earliest fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=774178
|
|
|
|
|
|
|
|
| |
Allows seeking through the available fragments that are still available
on the server as specified by the DVRWindowLength attribute in the
manifest.
https://bugzilla.gnome.org/show_bug.cgi?id=774178
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.html
http://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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use new gst_h264_video_calculate_framerate() API instead of fps_n/fps_d
fields in SPS struct which are to be removed.
Apparently H264 content in MSS is always non-interlaced/progressive,
so we can just pass 0 for field_pic_flag and don't need to parse any
slice headers first if there's no external signalling. But even if
that's not the case the new code is not worse than the existing code.
https://msdn.microsoft.com/en-us/library/cc189080%28VS.95%29.aspx
https://bugzilla.gnome.org/show_bug.cgi?id=723352
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=763081
|
|
|
|
|
|
|
|
|
| |
stream->current_fragment has the value of g_list_previous (iter) which has
just been checked. No need to check it again.
Just to be safe, use a g_assert() to check fragment before dereferencing.
CID #1352041
|
|
|
|
|
|
|
| |
Implement snap seek flags handling in stream_seek to allow the
parent class to handle it for us
https://bugzilla.gnome.org/show_bug.cgi?id=759158
|
|
|
|
|
| |
Otherwise it was always using the 'start' value, leading to wrong
behavior
|
|
|
|
|
| |
Some seeks are only updating the stop position, there is no need
to change the current downloading position.
|
|
|
|
|
| |
It can be used as a resource to verify if the server has updated
something in the Manifest when downloads are failing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adaptive demuxers need to start downloading from specific positions
(fragments) for every stream, this means that all streams can snap-seek
to a different position when requested. Snap seeking in this case will
be done in 2 steps:
1) do the snap seeking on the pad that received the seek event and
get the final position
2) use this position to do a regular seek on the other streams to
make sure they all start from the same position
More arguments were added to the stream_seek function, allowing better control
of how seeking is done. Knowing the flags and the playback direction allows
subclasses to handle snap-seeking.
And also adds a new return parameter to inform of the final
selected seeking position that is used to align the other streams.
https://bugzilla.gnome.org/show_bug.cgi?id=759158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
depth field can be retrieved from "BitsPerSample" or
from "WaveFormatEx" structure, if provided in Manifest
https://bugzilla.gnome.org/show_bug.cgi?id=758586
|
| |
|
|
|
|
|
|
|
|
| |
Doing the contrary has no effect and the consequence is that playback
will start with the lowest bitrate even if we can already handle
higher bitrate.
https://bugzilla.gnome.org/show_bug.cgi?id=755108
|
|
|
|
|
|
|
| |
If the manifest has a ProtectionHeader node then parse it and emit
protection events according to the specified protection SystemID.
https://bugzilla.gnome.org/show_bug.cgi?id=753613
|
|
|
|
|
|
|
|
|
| |
Not doing this can lead the demuxer to attempt downloading fragments
for an invalid start time. The server would then send a HTTP
Precondition failed error, the demuxer would try some more times to
download the invalid fragment and eventually error out.
https://bugzilla.gnome.org/show_bug.cgi?id=754523
|
|
|
|
| |
This is not needed any longer.
|
|
|
|
| |
downloaded
|
|
|
|
|
| |
Just freeing the url won't reset the byte ranges and can lead to wrong
ranges being used.
|
|
|
|
|
|
| |
Move the property from subclasses to adaptivedemux, it allows
selecing the percentage of the measured bitrate to be used when
selecting stream bitrates
|
|
|
|
|
|
| |
Allows to set a bitrate directly instead of measuring it internally
based on the received chunks. The connection-speed was removed from
mssdemux and hlsdemux as it is now in the base class
|
|
|
|
|
|
|
|
|
| |
q->bitrate is a guint64, but G_TYPE_INT may read fewer bits
off the stack, and if we pass more then the NULL sentinel
may not be found at the right place, which in turn might
lead to crashes.
https://bugzilla.gnome.org/show_bug.cgi?id=741751
|
|
|
|
|
|
|
|
|
| |
Rework reverse fragment traversing with repetition fields to prevent
NULL pointer deref and avoid never advancing a fragment as the variable
is unsigned and would always be non-negative.
CID #1257627
CID #1257628
|
|
|
|
|
| |
Implement the functions of adaptivedemux to have live support
enabled. This allows mssdemux to refresh the Manifest periodically
|
|
|
|
|
| |
For live streams this makes a difference when resyncing after a
Manifest refresh, otherwise it doesn't know where to restart
|
|
|
|
|
|
|
|
|
|
|
|
| |
Read the "r" attribute from fragments to support fragments nodes
that use repetition to have a shorter Manifest xml.
Instead of doing:
<c d="100" />
<c d="100" />
You can use:
<c d="100" r="2" />
|
| |
|