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
Alternates between 33 and 32 byte frames, but must start
with a 33 byte frame. This has been broken for ages since
the element was ported to the audio decoder base class.
https://bugzilla.gnome.org/show_bug.cgi?id=709416
This currently converts from ARGB64_F16 (16 bit float per component)
to ARGB64 by clipping. We should add support for the F16 format and
implement a conversion filter element that can apply gamma curves,
change exposure, etc.
It only gets the sink flag set when it adds the multifilesink, that
happens in null->ready and it might be too late. Set the flag
explicitly on the constructor.
https://bugzilla.gnome.org/show_bug.cgi?id=711086
This patch fixes three memory leaks in hlsdemux, one that occurs
during normal operation and two that occur during error conditions.
The gst_hls_demux_get_next_fragment function calls
gst_fragment_get_buffer which increments the reference count
on the buffer but gst_hls_demux_get_next_fragment never calls unref on
the buffer. This means that the reference count for each downloaded
fragment never gets to zero and so its memory is never released.
This patch adds a call to gst_buffer_unref after the flags have been
updated on the buffer.
There is a leak-on-error in gst_hls_demux_decrypt_fragment if it fails
to download the key file. If the key fails to download, null is
returned without doing an unref on the encrypted fragment. The
semantics of gst_hls_demux_decrypt_fragment is that it takes ownership
of the encrypted fragment and releases it before returning.
There is a leak-on-error in gst_hls_src_buf_to_utf8_playlist in the
unlikely event that the gst_buffer_map fails. In the "happy path"
operation of gst_hls_src_buf_to_utf8_playlist the buffer gets an unref
before the function returns, therefore the error condition must do the
same.
https://bugzilla.gnome.org/show_bug.cgi?id=710881
Fixed up the error-handling code when downloading fragments.
Modifed the error-handling code to use positive logic when
testing for cancellation of the download loop.
https://bugzilla.gnome.org/show_bug.cgi?id=701404
There is an issue for live streams where download_loop will keep
downloading segments until it gets a 404 error for a segment
that has not yet been published. This is a problem because this
request for a segment that doesn't exist will propagate all the
way back to the origin server(s). This means that dashdemux causes
extra load on the origin server(s) for segments that aren't yet
available.
This patch uses availabilityStartTime, period
and the host's idea of UTC to decide if a fragment is available to
be requested from an HTTP server and filter out requests for fragments
that are not yet available.
https://bugzilla.gnome.org/show_bug.cgi?id=701404
On some live HLS streams, gst_hls_demux_switch_playlist causes
assertion failures because it tried to dereference a NULL fragment.
This is because g_queue_peek_tail sometimes was returning NULL and
this case was not being checked.
This patch does two things:
* move the g_queue_peek_tail inside the semaphore protection
* check if q_queue_peek_tail returns NULL
https://bugzilla.gnome.org/show_bug.cgi?id=708849
gstdashdemux.c:1753: warning: format '%llu' expects type 'long long unsigned int', but argument 8 has type 'long unsigned int'
gstdashdemux.c:2224: warning: format '%llu' expects type 'long long unsigned int', but argument 9 has type 'guint64'
gstdashdemux.c:2224: warning: format '%llu' expects type 'long long unsigned int', but argument 10 has type 'guint64'
gstmpdparser.h:530: warning: type qualifiers ignored on function return type
gstmpdparser.c:4177: warning: type qualifiers ignored on function return type
including the following supports and fixes:
* Create DirectFB surfaces from GstBufferPool
* Add NV12 pixel format support
* Don't use the cursor in the exclusive mode
- EnableCusor() can be only used when the administrative mode is set
in DirectFB 1.6.0 and later.
* Support multiple plane rendering for planar color formats
- This accommodates the chroma plane offsets of the framebuffer
in planar formats.
* Invoke SetConfiguration regardless of video mode setting in setcaps()
- SetConfiguration() method should be invoked regardless of
the result of gst_dfbvideosink_get_best_vmode(), since the two are
unrelated.
* Disable DirectFB signal handler
- "--dfb:no-sighandler" option is passed to DirectFBInit().
This prevents DirectFB from trying to kill the process and allows
GStreamer's termination sequence to proceed normally.
https://bugzilla.gnome.org/show_bug.cgi?id=703520
For SegmentTemplate elements containing a startNumber attribute, the
`number' member of GstMediaSegments should be offset by the value of
startNumber; however, this is not currently the case. As a result, the
first URI(s) requested by the download loop will be wrong.
This commit ensures that segment numbers will be offset by startNumber
when one is present in a SegmentTemplate element.
https://bugzilla.gnome.org/show_bug.cgi?id=705661
When using a SegmentTemplate element, the timestamps of the buffers
output by dashdemux are incorrect, causing problems downstream.
The reason is that GstMediaSegment start times are calculated (in
gst_mpdparser_get_chunk_by_index) by multiplying segment index by
segment duration and then scaling the result according the `timebase'
attribute from the MPD. However, the segment duration is already a
GstClockTime (i.e., it has already been scaled according to the timebase
from the MPD and converted to a nanosecond value), so multiplying it by
the segment index will give the correct timestamp without the need for
any further scaling.
https://bugzilla.gnome.org/show_bug.cgi?id=705679
This prevents locking on startup when a stream only has a single buffer
for one of the streams and mssdemux decides to push an EOS event right
after it.
This prevents deadlocks on startup on files that have only a very
large buffer for a stream and the queue is filled and will lock on
the eos event that is pushed after the buffer. As no buffers have yet
been pushed to other streams, the pipeline locks on preroll
