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
Remove unnecessary helper struct for callbacks. The bclass
member of the helper struct was not used, so we can just
remove it and the GET_CLASS() call and simplify the whole
affair by passing the depayloader directly to the callback.
parsed, framed, stream-format and alignment are only relevant for parsers and
should not matter here. We still want to be able to use an encoder that can
only output byte-stream if the input was avc.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
Caps are cleaned up for missing plugins, and for creating encoding profiles
and caps descriptions.
Fields like streamheader, parsed, framed, stream-format and alignment are not
relevant here. The last ones all because a parser will take care of them.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
When a discont buffer is processed, the state is re-initialized, which
nullifies the allowed_tags.
The problem is when a subrip string with tags is processed and allowed_tags is
NULL. The function subrip_unescape_formatting() calls g_strjoinv with a
str_array as NULL, leading to a GLib-CRITICAL.
This patch removes the allowed_tags resetting, in parser_state_init(), but
move it into gst_sub_parse_format_autodetect().
https://bugzilla.gnome.org/show_bug.cgi?id=768525
We need to take into account the input segment flags to know whether
we should drain the decoder after a new keyframe in trick mode.
Otherwise we would have to wait for the next frame to be outputted (and
the segment to be activated) which ... well ... kind of beats the whole
point of this draining :)
And especially don't use the stream lock for that, as otherwise non-serialized
queries (CONVERT) will cause the stream lock to be taken and easily causes the
application to deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=768361
By default we'll wait for a certain amount of data before
attempting typefinding. However, if the stream is fairly
short, we might get EOS before we ever attempted any
typefinding, so at this point we should force typefinding
and output any pending data if we manage to detect the
type.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
In 0.10 the source pad was a dynamic pad that was only added once
the type had been detected, but in 1.x it's an always source pad,
so checking whether it's still NULL won't work to detect if the
type has been detected.
Makes tagdemux error out when we get EOS but haven't managed to
identify the format of the data after the tag.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
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.
Dropping a buffer because we have a seek pending is normal,
and will now happen when we trigger a seek while going through
the packets in a page. So this should not be an error.
