Since the refactoring of GstContext (commits
qc9fa2771b508e9aaeecc700e66e958190476f,
a7f5dc8b8a,
690326f906dc82e41ea58b81cdb2e3e88b754,
d367dc1b0d4ecb37f4d27267e03d7bf0c6c06a6, and
82d158aed3f2e8545e1e7d35085085ff58f18) I am no longer able to get
a shared context for an element that is used twice in a pipeline.
I used the documentation and eglglessink as my reference for
implementing the GstContext logic.
As the code was tied to a hardware decoder, I have ported the
GstContext code to fakesink to show the problem. Using the old
API a single ExampleMgr instance is created, but using the new
API each element is creating its own instance.
In some cases the wait for more data was happening without updating
the buffering state, meaning the API user would not be able to notice
it should pause the pipeline and update UI to indicate that is the
case, the video would likely stutter instead.
https://bugzilla.gnome.org/show_bug.cgi?id=707648
If the multiqueue has automatically grown chances are good that
we will cause the pipeline to starve if the maximum level is reduced
below that automatically grown size.
https://bugzilla.gnome.org/show_bug.cgi?id=707156
When a buffering query is handled it uses the get_buffering_percent()
function to get some statitics. Unfortunately this function also
calculates whether the queue should be buffering and adapts the
global queue2 state in case of state transitions from/to buffering
(including whether a buffering message was posted on the bus!).
This means that there is a race which can cause buffering messages
to never posted if the global state changes happen as a result of aa
query instead of resulting from bytes flowing in/out.
Spotted by Sjoerd Simons.
Change to only query state in get_buffering_percent() and update
state only in update_buffering().
https://bugzilla.gnome.org/show_bug.cgi?id=705332
When in download buffering mode queue2 didn't check if a range offset is
in a undownloaded range before the currently in-progress range. Causing
seeks to an earlier offset to, well, take a while.
When asked about the scheduling flags first check with upstream and
simply add the _SEEKABLE flag when using a temporary file as storage.
This enables the forwarding of _SEQUENTIAL and _BANDWIDTH_LIMITED from
sources if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=704927
A new active pad might not be notified in some cases, which results
in the current track number not being set in playbin.
The active-pad notification is only sent in the chain and sink_event
functions, and only when the buffer or event that triggered the active
pad selection is from the newly activated pad. So in the other case
the notification will never be sent.
https://bugzilla.gnome.org/show_bug.cgi?id=704691
We must be certain that we don't cause a deadlock when blocking the serialized
queries. One such deadlock can happen when we are buffering and downstream is
blocked in preroll and a serialized query arrives. Downstream will not unblock
(and allow our query to execute) until we complete buffering and buffering will
not complete until we can answer the query..
https://bugzilla.gnome.org/show_bug.cgi?id=702840
Otherwise we might get deadlocks caused by lock order inversion:
During the chain function the stream lock is first locked and then the
inputselector lock. During pad release we first locked the inputselector
lock and then deactivating the pad would lock the stream lock.
There's no reason why the inputselector lock should be required while
deactivating and removing the pad, it's only needed before.
https://bugzilla.gnome.org/show_bug.cgi?id=704002
We must be certain that we don't cause a deadlock when blocking the serialized
queries. One such deadlock can happen when we are buffering and downstream is
blocked in preroll and a serialized query arrives. Downstream will not unblock
(and allow our query to execute) until we complete buffering and buffering will
not complete until we can answer the query..
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=702840
During FLUSH_START the query needs to be unblocked already, otherwise
it can lead to deadlocks if the FLUSH_START is the result of something
done from the streaming thread of the srcpad (the queue will never be
emptied!).
Fixes some deadlocks during flushing.
And store queue items differently to not accidentially read
already unreffed queries when flushing. Queries are owned by
upstream and not us.
In the case the source has no caps, caps must be sent before segment. This
fixes few unit tests that where failing due to the new misordering warning.
https://bugzilla.gnome.org/show_bug.cgi?id=699968
There's no point in storing them and sending them later, and doing so would
later require to distinguish between events that should come before caps and
after.
https://bugzilla.gnome.org/show_bug.cgi?id=692784
API: GST_PLUGIN_STATIC_DECLARE()
API: GST_PLUGIN_STATIC_REGISTER()
Based on a patch by Håvard Graff <havard.graff@tandberg.com>.
This now allows GST_PLUGIN_DEFINE() to create a static plugin if
GST_PLUGIN_BUILD_STATIC is defined. The resulting plugin can be
statically linked or dynamically linked during compilation but
can't be dynamically loaded during runtime.
Also adds GST_PLUGIN_STATIC_DECLARE() and GST_PLUGIN_STATIC_REGISTER(),
which allows to register a static linked plugin easily.
It is still required to manually register every single statically linked
plugin from inside the application as this can't be automated in a portable
way.
A new configure parameter --enable-static-plugins was added that allows
to build all plugins we build here as static plugins.
Fixes bug #667305.
When querying a queue that is flushing we end up adding
a query to the queuearray without taking a reference to
that query (because the normal functionality is to block
until that query is done and discarded from the queue).
This later causes problem if the query is unreffed outside
of the queue before we discard the queue. There is a check
to avoid unreffing any lingering query-objects, but since
the query has been deleted that check fails.
This commit depends on other fixes done to gst_queue_array_find()
and gst_queue_array_drop_element().
https://bugzilla.gnome.org/show_bug.cgi?id=692691
The control of wheteher a SingleQueue is full is not correct.
Rewrote single_queue_overrun_cb() so it checks the correct variables
when checking if the queue has reached the hard limits, and to
increase the max buffer limit once for each call.
https://bugzilla.gnome.org/show_bug.cgi?id=690557
Implement the same behaviour as gst_pad_push_event when pushing sticky events
fails, that is don't fail immediately but fail when data flow resumes and upstream
can aggregate properly.
This fixes segment seeks with decodebin and unlinked audio or video branches.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=687899
In flush-on-eos=true mode any data remaining in the queue is
discarded when an EOS event is received, and the EOS passed
downstream as soon as possible (instead of waiting for all
buffers in the queue to get processed by downstream first).
May or may not be useful in capture/encoding scenarios.
Basetransform should not try to negotiate in passthrough mode but
respect the order of what we return in the transform_caps method.
A typical case is that you specify some specific new caps in the
caps property but also allow the current caps to pass.
Fix race that could cause data corruption when seeking in ring buffer
mode.
In perform_seek_to_offset(), called from the demuxer's pull_range
request, we drop the lock, tell upstream (usually a http source)
to seek to a different offset, then re-acquire the lock before we
do things to the ranges. However, between us sending the seek event
and re-acquiring the lock, the source thread might already have pushed
some data and moved along the range's writing_pos beyond the seek
offset. In that case we don't want to set the writing position back
to the requested seek position, as it would cause data to be written
to the wrong offset in the file or ring buffer.
Reproducible doing seek-emulated fast-forward/backward on 006653.
Conflicts:
plugins/elements/gstqueue2.c
Only one STREAM_START event should be let through, else it will
confuse downstream elements that think a new stream is starting
whereas in fact we are just switching to a different input.
In the future we might want to let them through but with the same
sequence number.
This guarantees a bit more consistency in which input stream will
be selected by default. It would previously be the first pad on which
an event/buffer/query was received ... which was racy and non-predictable.
