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.
Make state changes of internal elements more reliable by locking
their state, and ensuring that they aren't blocked pushing data
downstream before trying to set their state.
Add a boolean to avoid starting tasks when the main
thread is busy trying to shut the element down.
Try harder to make switching pads work better by
making sure concurrent downloads are finished before exposing
a new set of pads.
Release the manifest lock when signalling no-more-pads, as
that can call back into adaptivedemux again
If other stream fragments are still downloading but new streams
have been scheduled, don't expose them yet - wait until the last
one finishes. Otherwise, we can cancel a partially downloaded
auxilliary stream and cause a gap.
Drop the manifest lock when performing actions that might
call back into adaptivedemux and trigger deadlocks, such
as adding/removing pads or sending in-band events (EOS).
Unlock the manifest lock when changing the child bin state to
NULL, as it might call back to acquire the manifest lock when
shutting down pads.
Drop the manifest lock while pushing events.
ahssrc is a new plugin that enables Gstreamer to read from the
android.hardware.Sensor Android sensors. These sensors are treated as
buffers and can be passed through and manipulated by the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=768110
In this mode, we let WebRTC Audio Processing figure-out the delay. This
is useful when the latency reported by the stack cannot be trusted. Note
that in this mode, the leaking of echo during packet lost is much worst.
It is recommanded to use PLC (e.g. spanplc, or opus built-in plc).
In this mode, we don't do any synchronization. Instead, we simply process all
the available reverse stream data as it comes.
The calculation of the offset table was done base on a plane size
estimation. This does not always work. Instead, use memory offset the
same we as it's implement in GstVideoMeta map functions.
Fixing the following warning when generating documentation:
xml/element-gaussianblur.xml:72: element refsect2: validity error :
ID GstGaussianBlur already defined
<refsect2 id="GstGaussianBlur" role="typedef">
^
Warning: multiple "IDs" for constraint linkend: GstGaussianBlur.
DOC Fixing cross-references
Fixing the following warning when generating documentation:
xml/element-chromium.xml:74: element refsect2: validity error :
ID GstChromium already defined
<refsect2 id="GstChromium" role="typedef">
^
Warning: multiple "IDs" for constraint linkend: GstChromium.
DOC Fixing cross-references
In the case of KEY_UNIT and TRICKMODE_KEY_UNITS seeks, we want to
"snap" to the closest fragment.
Without this, we end up pushing out a segment which does not match
the first fragment timestamp being pushed out, resulting in one or
more buffers being eventually dropped because they are out of segment.
Compiler would complain about include directory that didn't
exist because QPA_INCLUDE_PATH gets subst-ed regardless
(and if it didn't we'd have just an empty -I argument).
https://bugzilla.gnome.org/show_bug.cgi?id=767553
This simplifies the code but also removes a bug with tracking of the remaining
size for the initial subfragment: we were not considering the size between the
index and the start of the first moof here.
https://bugzilla.gnome.org/show_bug.cgi?id=764684
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
