Age | Commit message (Collapse) | Author | Files | Lines |
|
We updated the common module without fixing up autogen.sh
|
|
autotools automatically generate this, and when using different versions
for autogen.sh there will always be changes to a file tracked by git.
|
|
From bc76a8b to c8fb372
|
|
From f2c6b95 to bc76a8b
|
|
From ef1ffdc to f2c6b95
|
|
From 7bb2bce to ef1ffdc
|
|
From 84d06cd to 7bb2bce
|
|
Fails faster now!
|
|
From a8c8939 to 84d06cd
|
|
From 36388a1 to a8c8939
|
|
|
|
|
|
Locking is all a bit weird in this test, but at least
it doesn't abort any longer.
|
|
Allows building checks without running them
|
|
We don't actually require 2.34, and 2.32 is what the
other modules currently require.
|
|
Making it possible to use Gnl with gst-launch (with patch from #732149)
|
|
In the composition many elements are not used, until now, they were
always set to the PAUSED state though it makes sense to be able to
do gapless playback it is sometimes not ideal to preserve memory
usage and it means the more children the composition has the more
threads are used and it is very simple to reach the kernel hard
limit number of threads. In order to avoid that to happen, we set
default state of unused thread to READY and we add a property to
the composition so that users can override that default behaviour.
+ Make sure we send "stream-start" again when changing our ghostpad to
avoid "Data flow before stream-start assertion"
+ Fix unit tests, do not check refcount when changing state as it can
vary.
https://bugzilla.gnome.org/show_bug.cgi?id=596849
|
|
From 211fa5f to 1f5d3c3
|
|
Make sure we don't let buffers pass before our entry
got correctly seeked and had a segment when updating
the pipeline
|
|
Most test rely on the common helper to handles that,
but for seeking tests it does not make sense to handle it that way (as
in gnlcomposition we send 2 seeks when we get seek and thus we can received
2 times the same segment)
|
|
Handle it in the tests as it is not critical
|
|
|
|
From bcb1518 to 211fa5f
|
|
|
|
|
|
|
|
|
|
From fe1672e to bcb1518
|
|
From 1a07da9 to fe1672e
|
|
From d48bed3 to 1a07da9
|
|
ret is only set before leaving the loop.
COVERITY CID 1139661
COVERITY CID 1139662
|
|
From dbedaa0 to d48bed3
|
|
|
|
From 865aa20 to dbedaa0
|
|
|
|
|
|
From 6b03ba7 to 865aa20
|
|
From b613661 to 6b03ba7
|
|
From 74a6857 to b613661
|
|
From 01a7a46 to 74a6857
|
|
And always update start/duration when removing an object from the
composition
|
|
There is no reason to keep it and in some rare cases it creates
deadlocks as followed:
t1:
→ Composition receives a flushing seek, it takes the OBJECTS_LOCK
and fowards the flushing seek event upstream
→ adder receives the seek and set its collectpad to flushing
This implies tacking STREAM_LOCK (collectpad)
t2:
→ Collectpad has buffers ready, and has the STREAM_LOCK
(collectpad) and is EOS, so it sends it downstream
→ The composition receives EOS, and needs to check if it is
the actual EOS or not, thus need to take the OBJECTS_LOCK
This create a deadlock, and in the first stage, we did not need the
OBJECTS_LOCK to forward downstream the flushing seek, so do not take
it.
https://bugzilla.gnome.org/show_bug.cgi?id=706831
|
|
|
|
It ensures that all data that still flows while we update the
pipeline is dropped, otherwise we have races where we could get
buffer from the old pipeline flowing into elements that are already
fully flushed (and have no segment caps, etc... set)
Also validate the stack a little later.
This commits finnishes what had been started with
a24a3be13b81c5d0080c061edf61daece6341f95
|
|
There is a race where we can have an EOS from the element which
srcpad is our ghost pad but other elements upstream are still outputing
data and we flush the element so its pads have no segment info
anymore, and we end up having warning about flow before segement event.
The solution here is that we do not let any data flowing when we are
updating the pipeline.
|
|
Fixes warnings with automake 1.14
https://bugzilla.gnome.org/show_bug.cgi?id=705350
|
|
When checking for request pads as fallback, just look at the
element's class, not the factory, since there might not be
a factory (in case of python elements) or the factory might
be the wrong one (in case of a GstBin sub-class) and doesn't
have complete information.
https://bugzilla.gnome.org/show_bug.cgi?id=582244
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=701647
|
|
The object can be removed at the time the pad is removed, avoid segfaulting
when that happens.
|
|
Avoiding races where the pad would be added right between the connection
and inserting to the hashtable
|