All streams that have the same group id are supposed to be played
together, i.e. all streams inside a container file should have the
same group id but different stream ids. The group id should change
each time the stream is started, resulting in different group ids
each time a file is played for example.
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
This makes sure that no bin misses the clock-lost messages, independent
of the state, and could return an old, non-working clock from
gst_bin_provide_clock_func().
https://bugzilla.gnome.org/show_bug.cgi?id=701997
Fixes compiler warnings such as
gstallocator.c:61:8: error: conflicting types for 'gst_memory_alignment'
../gst/gstallocator.h:52:18: note: previous declaration of 'gst_memory_alignment' was here
Renegotiation and reconfiguration will fail because all queries
and events won't be accepted by the pad if it's flushing. In the
best case this just causes unneeded work and spurious warnings in
the debug logs, in the worst case it causes elements to fail completely.
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
Pass the fixed caps we're asked to accept as a filter for the caps
query, so we don't get a fully-expanded set of caps back (which we don't
need and can take a lot of time for intersection).
This reduces the time for camerabin to produce a second frame on a
logitech C910 camera from around 52 seconds to a bit less then 16
seconds on my system.
https://bugzilla.gnome.org/show_bug.cgi?id=702632
When appending/prepending tags, avoid re-creating (and copying) lists if we already
have one and instead just append/prepend the GValue to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=702545
When we asynchronously go from READY to PLAYING, also call the
state change function so that subclasses can update their state for PLAYING.
Because the PREROLL lock is not recursive, we can't make this without
races and we must assume for now that the subclass can handle concurrent calls
to PAUSED->PLAYING and PLAYING->PAUSED. We can make this assumption because not
many elements actually do something in those state changes and the ones that
did would be broken even more without this change.
https://bugzilla.gnome.org/show_bug.cgi?id=702282
The check is done using curl (if available). It lists the curl exit code + http
status code (for those > 399) together with the use of the url in the code. The
check is not fatal.
