Make GstPluginFeature opaque until we have time to
clean it up a little. Only GstElementFactory and
GstTypefindFactory derive from it, and they are
opaque already, and we currently don't support
custom plugin features in the registry anyway.
Add a prepare method that is called before sync happens. The purpose of this
method is to prepare the rendering of the giving buffer so that the following
render() call after sync is a quick as possible.
In gst_base_src_start_complete() we do a perform_seek() that will eventually
start the streaming thread which acquires the live lock and then goes to sleep
in the case of appsrc. Right after we perform seek we also try to acquire the
live lock which might then deadlock.
fix this by taking the stream lock before performing the seek. This makes sure
that the streaming thread cannot start and grab the live lock until we are done
and release the stream lock again.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676048
In commit bf0964b6 a check for pad is activated was not carried.
This leads to attempt to pull while in push mode when force_caps
is set. In this case without the attached check even when activated
in pull mode we activate back to push mode.
This is from comment in previous code , case number eight:
8. if the sink pad is activated, we are in pull mode. succeed.
- otherwise activate both pads in push mode and succeed.
Putting it back fixes playback of webm in webkit+gstreamer 1.0 .
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676003
This allows subclasses to override it, as is necessary for e.g. the
video-crop meta. It is now necessary that after decide_allocation()
there is always a allocator and a configured buffer pool inside the
query.
It causes the timestamp to go wrong, should not cause much of a performance
increase and in the cases where it is faster, it is broken in 0.10 as well.
We should try to review this when rewriting the adapter for 0.11 memory
features.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=674791
They can be used to select snapping behavior (to previous, next, or
nearest location, where relevant) when seeking.
The seeking implementation (eg, demuxer) may currently ignore some
or all of these flags.
It's only used internally, most other users will likely
want to use gst_registry_find_plugin() directly instead
(and if not, they can easily walk the list and doing the
strcmp themselves).
There's no reason anyone would want to derive from this, so
just make opaque until we manage to make all the private bits
private properly (which I'm not doing right now because it's
more invasive and I have registry modifications locally which
touch all that code as well).
