This avoids ending up with plenty of pending data (since we'll only
try to parse/push one frame from the incoming buffer).
Fixes increasing memory consumption when parsers aren't linked
Conflicts:
libs/gst/base/gstbaseparse.c
Separate the bufferpool and allocator hints in the allocation query, some
of the values don't always make sense together.
Keep the bufferpool and its configuration together.
Keep the allocator and its parameters together.
Allow for multiple bufferpool configurations in the query.
Previously only the last would be pushed, which would cause
invalid running times downstream. This also fixes the handling
of update newsegment events.
The segment start adjustment code in pull mode should never trigger
anymore because the bisection code earlier would have already made
sure that we're at the desired position.
Also move the gap handling some lines below after sending the currently
configured segments. Otherwise we might fill gaps in a segment that is
not configured downstream yet.
Make it possible to configure a GDestroyNotify and user_data for
gst_memory_new_wrapped() this allows for more flexible wrapping of foreign
memory blocks.
Use a frame flag to signal to subclass it should reset any retained
state w.r.t. frame parsing since the frame being passed is 'new',
i.e. not related to previously passed and processed data.
Make the pad activation code look more like other activation code.
Only start the sinkpad task when we decide to activate in pull mode, when we
later add srcpad pullmode this will be needed.
... so as to allow the push-mode case to provide data to subclass
on a buffer by buffer basis (as in regular forward case), rather
than all buffers of a fragment chucked together.
Also refactor buffer handling some more, and add some debug.
... since that is already handled by _update_duration, or should not be done
altogether if the duration is determined by non-estimated means.
Fixes#669502.
GstBaseParse was not clearing its adapter on reset causing
problems when a pipeline went for example from PLAYING to NULL
state and then back to PLAYING again. The data from the last
stream would be used in the parser.
https://bugzilla.gnome.org/show_bug.cgi?id=667444
There are many good use cases for GstIndex and we want
to add it back again in some form, but possibly not with
the current API, which is very powerful (maybe too powerful),
but also a bit confusing. At the very least we'd need to
make the API bindings-friendly.
Conflicts:
libs/gst/base/gstbasetransform.c
libs/gst/controller/gstinterpolationcontrolsource.c
libs/gst/controller/gstlfocontrolsource.c
plugins/elements/gstfilesrc.c
Dit not merge controller or basetransform changes.
Conflicts:
gst/gstindexfactory.c
libs/gst/base/gstbasetransform.c
plugins/elements/gstfakesink.c
plugins/elements/gstfakesrc.c
plugins/elements/gstidentity.c
plugins/elements/gstinputselector.c
plugins/elements/gstoutputselector.c
Note: did not merge any of the basetransform changes from 0.10.
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We can't change most of
these in 0.10 because they're part of our API and ABI.
