When connecting a demuxer through a multiqueue ensure to copy sticky
events in order to allow the following factory being properly
checked that it is functional.
https://bugzilla.gnome.org/show_bug.cgi?id=769580
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
When processing EOS for a pad, send a stream-group-done
for the pad in case downstream is waiting for more
data on this stream before it can process related
streams from the group.
https://bugzilla.gnome.org/show_bug.cgi?id=768995
My collection leak fix 83f30627cd
introduced a crash in this scenario: audiotestsrc ! decodebin3 ! fakesink
The reference handling of collection in decodebin3 wasn't very clear and
my attempt to fix the leak introduced a regression where we went one
reference short in some other scenarios.
Fixing this by:
- Giving a strong reference to DecodebinInput making things clearer
- Fixing get_merged_collection() which was sometimes returning an
existing reference and sometimes a new one.
https://bugzilla.gnome.org/show_bug.cgi?id=769080
The collection owned by GstDecodebin3 has to be unreffed when disposing.
gst_event_new_stream_collection() doesn't consume the collection passed
to it so no need to give it an extra ref.
https://bugzilla.gnome.org/show_bug.cgi?id=768811
MultiQueueSlot owns a ref on the active stream so it should release it
when being freed.
DecodebinInputStream owns ref on the active and pending stream so they
should be dropped when being freed.
https://bugzilla.gnome.org/show_bug.cgi?id=768811
gst_stream_get_caps() returns a reffed caps.
The caps passed to gst_query_set_caps_result() are not transfered.
The caps in gst_parse_pad_stream_start_event() was either acquired
using gst_pad_get_current_caps() which returns a new ref or
explicitly reffed.
https://bugzilla.gnome.org/show_bug.cgi?id=768811
With contributions from Jan Schmidt <jan@centricular.com>
* decodebin3 and playbin3 have the same purpose as the decodebin and
playbin elements, except make usage of more 1.x features and the new
GstStream API. This allows them to be more memory/cpu efficient.
* parsebin is a new element that demuxers/depayloads/parses an incoming
stream and exposes elementary streams. It is used by decodebin3.
It also automatically creates GstStream and GstStreamCollection for
elements that don't natively create them and sends the corresponding
events and messages
* Any application using playbin can use playbin3 by setting the env
variable USE_PLAYBIN3=1 without reconfiguration/recompilation.
We take a ref before removing which was never freeded.
The element is still alive anyway because the group has its own ref as
well.
Fix a leak with the 'test_suburi_error_wrongproto' test.
https://bugzilla.gnome.org/show_bug.cgi?id=766515
When we initialize an element in decodebin, we 1) set it to PAUSED and
push sticky events on its sinkpad to trigger negotiation 2) block its
src pad(s) to detect CAPS events. We can't block before 1) as that
would lead to a deadlock.
It's possible (and common) tho that an element configures its srcpad
during 1) and before 2). Therefore before this change we would
typically block and expose an element's pad only once the element
output its first buffer, triggering sticky events to be resent. One
consequence of this behaviour is that it sometimes broke
renegotiation.
With this change now we consider a pad ready to be exposed when it's
->blocked or has fixed caps (which were set before we could block it).
https://bugzilla.gnome.org/show_bug.cgi?id=765456
If we are configured to use buffering and there is no demuxer in the chain, we
still want a multiqueue, otherwise we will ignore the use-buffering property.
In that case, we will insert a multiqueue after the parser or decoder - not
elsewhere, otherwise we won't have timestamps.
https://bugzilla.gnome.org/show_bug.cgi?id=764948
When blocking the subtitle pad, it's expected that stream-start
is the first event, and that it can precede caps arriving on the
peer pad - in fact the caps can only have arrived on the peer
pad when it was pre-primed with sticky events previously.
Instead, just pass the stream-start and don't block, because
stream-start is sticky anyway.
There's a small window between decodebin choosing a buffering level
to post and another thread choosing a different buffering level
where things can race. Close that window by holding a new lock
that's only for posting buffering messages - like what was done
in multiqueue.
https://bugzilla.gnome.org/show_bug.cgi?id=764020
In check_upstream_seekable function, it returns FALSE value even though
we already declare about the seekable variable. So, This patch return
result of seekable in check_upstream_seekable function.
https://bugzilla.gnome.org/show_bug.cgi?id=763975
Due to transient locked state during autoplugging, some elements might be
ignored by the GstBin::change_state() and might still be running. Which could
then cause pad-added and similar accessing decodebin state that does not exist
anymore, and crash.
https://bugzilla.gnome.org/show_bug.cgi?id=763625
In other places we lock it the other way around, leading to possible
deadlocks. Also this will deadlock if analyze_pad() causes a new element to be
autoplugged that adds new pads on itself when its state is changed.
https://bugzilla.gnome.org/show_bug.cgi?id=763491
This reverts commit 0615794300.
deinterlace was ported at some point in the last 4 years and has better video
format support, and especially better negotiation than avdeinterlace. Having
avdeinterlace but not deinterlace causes various problems in zerocopy
scenarios.
https://bugzilla.gnome.org/show_bug.cgi?id=760553
When getting caps of the decode chain, in get_topology, the caps are being
checked if fixed or not. But get_topology will be called when the decode is
chain is being exposed and hence it will always be fixed. Hence removing the
check for fixed caps. Removing gst_pad_get_current_caps for the chain->pad, as
get_pad_caps will again call the same api.
And get_topology can return NULL value if currently shutting down the
pipeline, which on being passed to create message will result in assertion
error. Check if topology is valid before using it
https://bugzilla.gnome.org/show_bug.cgi?id=755918
analyze_new_pad() can return a new decode chain, which might have a new
GstDecodePad in the end. We should use those two for expose_pad() and not the
original ones that were passed to analyze_new_pad().
This fails when having a demuxer element that has raw pads immediately or
if a decoder with raw caps is after an adaptive demuxer.
https://bugzilla.gnome.org/show_bug.cgi?id=760949
