| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
harder ? :)
|
|
|
|
| |
You know, before it's used.
|
|
|
|
|
|
|
|
| |
Every encrypted fragment will be a multiple of 128 bits, the last byte
contains the number of bytes that were added as padding in the end
and should be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=701673
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using an HLS encrypted stream, an assertion failure is thrown:
(gst-launch-1.0:31028): GLib-GObject-WARNING **: cannot register
existing type `GstFragment'
(gst-launch-1.0:31028): GLib-CRITICAL **: g_once_init_leave: assertion
`result != 0' failed
Eventually tracked this down to the call gst_fragment_new()
in function gst_hls_demux_decrypt_fragment.
The GstFragment class is defined in ext/hls/gstfragment.c and in
gst-libs/gst/uridownloader/gstfragment.c. Having two class definitions
with the same name causes the assert failure when trying to allocate
GstFragment. Deleting the version from hls and editing the
Makefile.am solves this assert failure.
https://bugzilla.gnome.org/show_bug.cgi?id=704555
|
|
|
|
| |
srcpads
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=702722
|
|
|
|
|
|
| |
It should return True when the queue IS full
Fixes #704226
|
|
|
|
|
|
|
| |
Checks if the queue is full according to max buffering time
set by the user
https://bugzilla.gnome.org/show_bug.cgi?id=701404
|
|
|
|
|
|
| |
Split one very large function into 2 smaller but still large functions.
Also change the if conditions to positive checks to improve readability.
|
|
|
|
|
|
|
|
|
|
|
| |
During a live stream it is possible for dashdemux to lag behind on a
slow connection or to rush ahead of the connection os too fast.
For the first case it is necessary to jump some segments ahead to be able to
continue playback as old segments are usually deleted from the server.
For the later, dashdemux should wait a little before attempting another
download do give time to the server to produce a new segment
|
|
|
|
|
|
|
|
|
| |
When using a template based segment list, do not try to
contruct a finite segment list for the limits of the available periods.
We might not know when the period ends (for live streams) and we can
always create the segment on demand when requested by dashdemux,
avoiding use of some memory and cpu when re-creating this list.
|
|
|
|
|
|
|
|
|
|
|
| |
Replaces the 2 likely larger lists with more appropriate structures
to improve performance.
Replaces S nodes GList for a GQueue, this reduces latency to startup
because of traversing the list just append an element.
Replaces the processed media segments GList for a GPtrArray as it is
constantly acessed by index during playback.
|
|
|
|
|
| |
Set live if stream is live and also add to the max latency the
max internal buffering
|
|
|
|
|
|
| |
Duration from segment being unknown is a issue from the MPD and not
a programming issue, so the assert isn't useful here. Instead check
and return an error code so the caller can fallback to alternatives
|
|
|
|
|
| |
Always remember to unref the event before proceeding, in both success
and failure cases
|
|
|
|
|
|
| |
Removing unused function, replacing // comments with /* */ and
replacing some GST_WARNING with GST_INFO/_DEBUG as they are meant
to be
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When dashdemux selects its first fragment, it always selects the
first fragment listed in the manifest. For on-demand content,
this is the correct behaviour. However for live content, this
behaviour is undesirable because the first fragment listed in the
manifest might be some considerable time behind "now".
The commit uses the host's idea of UTC and tries to find the
oldest fragment that contains samples for this time of day.
https://bugzilla.gnome.org/show_bug.cgi?id=701509
|
|
|
|
| |
Simple fix to avoid an assertion.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the MPEG-DASH spec, certain elements (i.e.
SegmentBase, SegmentTemplate, and SegmentList) should inherit
attributes from the same elements in the containing AdaptationSet
or Period.
Updated the SegmentBase, SegmentTemplate, and SegmentList parsers
to properly inherit attributes from the corresponding elements in
AdaptationSet and/or Period.
https://bugzilla.gnome.org/show_bug.cgi?id=702677
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert all xml attribute/content parsing functions to return a
boolean value indicating whether or not the attribute/content was
present. We need this finer-grained control in order to properly
implement the inheritance policies described in the spec
Also fixed several memory leak conditions when handling errors in
the xml attribute/content parsing functions.
https://bugzilla.gnome.org/show_bug.cgi?id=702677
|
|
|
|
| |
It isn't a warning/issue.
|
|
|
|
|
| |
Check if the list has elements before trying to access the last one
and causing a segfault
|
|
|
|
| |
Avoids criticals when downloaded fragment is NULL
|
|
|
|
|
|
|
| |
If no initialization segment is defined, then don't print a
critical or a warning, just ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=701961
|
|
|
|
|
| |
Only create new string if required, saving maybe 1 or 2 str copies per
fragment.
|
|
|
|
|
| |
Return index URI/range to dashdemux from the mpdparser to be able
to download and deliver them downstream for playback.
|
|
|
|
|
|
|
| |
Parse and provide access to top-level index segments if available.
dashdemux should push those whenever a header is pushed.
Fixes #700489
|
|
|
|
|
|
|
|
|
|
| |
Issue evinced by
http://yt-dash-mse-test.commondatastorage.googleapis.com/car-20120827-manifest.mpd
which produces output like ** (gst-launch-1.0:8060): CRITICAL **:
gst_mpdparser_get_initializationURL: assertion `InitializationURL->sourceURL
!= NULL' failed
https://bugzilla.gnome.org/show_bug.cgi?id=700489
|
|
|
|
| |
Do not try to access range data if there is no segment node
|
|
|
|
| |
Makes debugging easier
|
|
|
|
|
|
|
|
| |
Use the mediaRange information and pass it to the uridownloader
to correctly download only the segment ranges indicated in the
MPD
https://bugzilla.gnome.org/show_bug.cgi?id=702206
|
| |
|
|
|
|
| |
The types are used in both the encoder and decoder
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that g_free/xmlFree is used correctly based on how the
memory was allocated.
When deallocating GLists, there were many places that were using
g_list_foreach and g_list_free. Converted these occurrences to
call g_list_free_full.
Add NULL checks to all xmlFree calls since the documentation does
not guarantee that passing NULL is safe
In places where we are strdup'ing memory allocated by libxml2,
changed those calls to use xmlMemStrdup().
There were several places where we were missing g_slice_free when
deallocating a top-level node structure.
https://bugzilla.gnome.org/show_bug.cgi?id=702837
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The enums should not be dist-ed and instead be re-generated when
compiling.
|
|
|
|
|
|
|
| |
Wayland interface could offer two buffers pixels formats: WL_SHM_FORMAT_XRGB8888 and WL_SHM_FORMAT_ARGB8888.
Update waylandsink to support them and check if the format is really available.
https://bugzilla.gnome.org/show_bug.cgi?id=702112
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=702297
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes:
In file included from gstsegmentation.h:51:0,
from gstopencv.c:42:
/usr/include/opencv2/video/background_segm.hpp:47:16: fatal error: list:
No such file or directory
#include <list>
^
compilation terminated.
https://bugzilla.gnome.org/show_bug.cgi?id=702297
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=702036
|
|
|
|
|
|
|
| |
Add an element to the opencv plugin for foregroung/background image
sequence segmentation, using one out of 3 algorithms.
https://bugzilla.gnome.org/show_bug.cgi?id=701421
|
| |
|
|
|
|
| |
It's fixed in the latest firmware since a few weeks.
|