But only add this for non-live playlists. For live playlists we already
have another thread that is periodically updating playlists.
Reason for this is that sometimes downloading a fragment can fail because
the URIs have changed or expired since last time.
Sequence numbers in different playlists are not guaranteed to be the same for the
same position, e.g. fragments could have different durations in different playlists.
In theory we should do exactly the same for live playlists, but unfortunately we can't
because doing this kind of seeking requires the complete playlist since we started
playback. For live playlists the server is however dropping fragments in the beginning
over time and we have no absolute time references.
The tag was dereferenced earier. From the libschroedinger code,
it's not obvious to see whether tag and frame would be NULL at
the same time. I think is likely that both will be non NULL
here, but that's not certain. Additional tests may be needed
to avoid dereferencing tag and/or frame, but what to do if
only one is NULL isn't obvious, as the _get_tag function does
transfer ownership so isn't undoable.
Coverity 1139850
When we'd see an unknown stream type, then a SDDS stream.
Then we'd get to the end of the switch with a NULL temp stream
pointer, and dereference it.
Coverity 1139708
Recent refactoring causes this code to be called with either a NULL
fragment, or a non NULL fragment. In the former case, we don't have
a buffer. In the latter case, the original code dealing with DISCONT
assumed the buffer was valid. Testing for a NULL buffer here thus
does not seem to change the intent, and fixes:
Coverity 1195147
Turns out there was the same issue as with subtitles.
There is space for a single audio stream, but up to 255
may be used based on a uint8_t value in a struct, which may
or may not be read from the (untrusted) data.
A comment in ifo_types.h says this value is either 0 or 1, so
we can ensure this here without drawbacks.
Coverity 1139585
There is space for a single subtitle stream, but up to 255
may be used based on a uint8_t value in a struct, which may
or may not be read from the (untrusted) data.
A comment in ifo_types.h says this value is either 0 or 1, so
we can ensure this here without drawbacks.
Coverity 1139586
There is a small chance that we might end up in the done step without
having any output available.
Furthermore, when going through not_ready, we need to ensure gst_buffer_unmap
has a properly initialized GstMapInfo.
CID #1139923
CID #1139924
CID #1139919
CID #1139920
gst_gl_context_create() might need to dispatch some operations to the
application's main thread, and calling this in the change_state function
can cause deadlocks.
* picked from old libgstegl:
- GstEGLImageMemory
- GstEGLImageAllocator
- last_buffer management from removed GstEGLImageBufferPool
* add-ons:
- GstEGLImageMemory now old a reference on GstGLContext
so that it can delete the EGLImage and its gltexture source
while having the associated gl context being current.
- add EGLImage support for GstVideoGLTextureUploadMeta which
mainly call EGLImageTargetTexture2D
- GstGLBufferPool now supports GstEGLImageAllocator
- glimagesink / glfilters / etc.. now propose GstEGLImageAllocator
to upstream
https://bugzilla.gnome.org/show_bug.cgi?id=703343
We create our textures (in Desktop GL) with GL_TEXTURE_RECTANGLE,
vaapi attempts to bind our texture to GL_TEXTURE_2D which throws a
GL_INVALID_OPERATION error and as thus, no video.
Also, by moving exclusively to GL_TEXTURE_2D and the npot extension
we also remove a difference between the Desktop GL and GLES2 code.
https://bugzilla.gnome.org/show_bug.cgi?id=712287
Fix bug #310775
gst-launch audiotestsrc ! libvisual_gl_projectM ! glimagesink is working
but for now you cannot append any other opengl filters between
libvisual_gl_projectM and glimagesink because our FBO is turned OFF.
It would require that libvisual allows to split rendering between
pass1,2,3... and final rendering. In order to unbind our FBO before
the passN, and then rebind it just before the final libvisual rendering.
hlsdemux causes a null pointer dereference if the media playlist
does not contain any media files. The gst_m3u8_client_get_duration
function assumes that demux->client->current->files is valid when
computing duration.
gst_m3u8_client_update needed to be modified to check for the
case of downloading an M3U8 file that doesn't contain any media
files, and returning an error to gsthlsdemux.c
This bug can be reproduced by creating a master m3u8 file that
contains one media playlist that points back to the master m3u8
file. For example create a file called bug725134.m3u8:
#EXTM3U
#EXT-X-VERSION:4
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=1251135, CODECS="avc1.42001f mp4a.40.2", RESOLUTION=640x352
bug725134.m3u8
https://bugzilla.gnome.org/show_bug.cgi?id=725134
hlsdemux does not check for the '"' character in #EXT-X-STREAM-INF
attributes. The CODECS parameter is an example of an attribute
that might use the '"' symbol and might contain a ',' character
inside this quoted string.
For example: CODECS="avc1.77.30, mp4a.40.2"
hlsdemux does not correctly parse the RESOLUTION attribute, it
assumes that an '=' character is used to delineate the width
and height values, but the HLS RFC states that a 'x' character
must be used as the delimiter between width and height.
https://bugzilla.gnome.org/show_bug.cgi?id=725140
...instead of adding them from the start of playlist every time. This
among other things fixes timestamps for live streams, where the playlist
is some kind of ringbuffer of fragments and thus adding from the beginning
of the playlist will miss the past fragments.
https://bugzilla.gnome.org/show_bug.cgi?id=724983
We now download fragments as fast as possible and push them downstream
while another thread is just responsible for updating live playlists
every now and then.
This simplifies the code a lot and together with the new buffering
mode for adaptive streams in multiqueue makes streams start much faster.
Also simplify threading a bit and hopefully make the GstTask usage safer.
Incorrect time scaling in gst_dash_demux_wait_for_fragment_to_be_available()
means that media segments are fetched before their availablity time. This
patch fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=724875
demux->last_manifest_update is not initialised at startup, with the
effect that live manifests are reloaded immediately after the download
loop begins. This patch fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=724790
And only afterwards wait until a fragment was played. Otherwise we're keeping
our cache most of the time at "fragments-cache" fragments minus one.
Also allow setting "fragments-cache" to 1 now to start playback even faster.
Use glib to get a list of system "share" directories, then go through that
list, appending 'sounds/sf2/' to each directory to get a soundfont directory,
and looking for .sf2 files there.
This way fluiddec is able to load sf2 files on W32, because otherwise the
path '/usr/share/sounds/sf2' makes no sense there.
Fixes#724013
nettle is used by newer versions of gnutls, while older versions of gnutls
used libgcrypt. Support both for now as not every distro has nettle yet.
nettle is preferred as it is more efficient to use and much smaller.
This will be incredible slow if the upstream block size is very small. Instead
continue scanning for the header where we previously stopped.
For the standard filesrc block-size this made decoding a file about
3 times faster.
https://bugzilla.gnome.org/show_bug.cgi?id=719890
Merge various changes and fixes from the master mpegdemux
Performance improvement from the way streams are organised,
return flow combining, language tag event generation,
adjustments and fixes in debug output, and things like that.
Previously faces would only be detected if they were at least 30x30 pixels
large and at most 32x32 pixels. We keep the minimum setting (maybe needs
a property as in facedetect) but disable the maximum feature size.
See https://bugzilla.gnome.org/show_bug.cgi?id=722158
This disables the "max feature size" feature. The current configuration
is totally busted: The max feature size is hard-coded to 2 pixels more
than the user-supplied min feature size which pretty much means you need
to guess the size of the person's face to within a few pixels to get the
code to find it.
https://bugzilla.gnome.org/show_bug.cgi?id=722158
Remove the dashdemux seeking function to use the one implemented
in mpdparser as it is more complete. This also makes dashdemux not
crash when seeking on streams that use segment templates.
1275 is the maximum size of a frame, but the encoder may return
up to 3 frames, and we need a few extra bytes for TOC, etc. We
use 4000, which is a bit more, and suggested in the libopus docs.
Download and push from the same task, makes code a lot simpler
to maintain. Also pushing from separate threads avoids deadlocking
when gst_pad_push blocks due to downstream queues being full.
Use a single lock for all streams instead of having separate locks.
This makes maintenance easier and at most points we would need
a single lock before iterating on all streams data. So not much
is gained from individual locks.
Make dash playlists with multiple periods work again by waiting
to switch the periods when all streams have reached the end of
the current period. The stream_loop is responsible for advancing
the period, but the download loops will already start downloading
data for the next period as soon as possible.
Handle multiple languages by using the not-linked return to stop
the download task for that stream. It can be reactivated when
a reconfigure event is received. Stopping the unused streams is
relevant to save network bandwidth
Instead of having a single download task for all streams, this
commit makes each stream have its own download loop, allowing
parallel download of fragments.
always expose all streams instead of only exposing one of each type.
This is more aligned with gstreamer's way of working. Allows the user
to select the stream that it wants to use by linking its pad and leaving
the unused ones as unlinked.
As streams now flow independently, the GstSegment needs to be put
on each stream so they can track the position of each one correctly
instead of being mixed in a single segment
Download and push from the same task, makes code a lot simpler
to maintain. Also pushing from separate threads avoids deadlocking
when gst_pad_push blocks due to downstream queues being full
When a stream gets a not-linked return, it will be marked as so and
won't download any more new fragments until a reconfigure event
is received. This will make mssdemux expose all pads, but only download
fragments for the streams that are actually being used.
Relying on the pads being linked/unlinked isn't enough in this scenario
as there might be an input-selector downstream that is actually discarding
buffers for a given linked pad.
When streams are switching, the old active stream can be blocked because
input-selector will block not-linked streams. In case the mssdemux's
stream loop is blocked pushing a buffer to a full queue downstream it will
never unblock as the queue will not drain (input-selector is blocking).
In this scenario, stream switching will deadlock as input-selector is
waiting for the newly active stream data and the stream_loop that would
push this data is blocked waiting for input-selector.
To solve this issue, whenever an stream is reactivated on a reconfigure
it will enter into the 'catch up mode', in this mode it can push buffers
from its download thread until it reaches the currrent GstSegment's position.
This works because this timestamp will always be behind or equal to the maximum
timestamp pushed for all streams, after pushing data for this timestamp,
the stream will go back to default and be pushed sequentially from the main
streaming thread. By this time, the input-selector should have already
released the thread.
https://bugzilla.gnome.org/show_bug.cgi?id=711849
* ext/srtp/gstsrtp.[ch]: added GST_SRTP_CIPHER_AES_256_ICM to
GstSrtpCipherType and new function cipher_key_size.
* ext/srtp/gstsrtpenc.c: maximum key size is now 46 characters (14 for
the salt plus the key). If different ciphers are chosen for RTP and
RTCP the maximum needed key size is expected.
* ext/srtp/gstsrtpdec.c: minor documentation updates.
https://bugzilla.gnome.org/show_bug.cgi?id=720434
