Otherwise calls to get the clock time might change its internal state
and the internal/external time for calibration get unbalanced leading to
a clock jump
https://bugzilla.gnome.org/show_bug.cgi?id=740834
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.
Also it ensure that we always have a clean state before start(), cleaned the
same way in every case.
The same was done already in the decoder, and we cleaned some state just above
manually that would also be taken care of by reset().
This makes sure that the element is in the same state before start() is called
the very first time and every future call after the element was used already.
The stop() vfunc might mess with some of our fields we have just
reset, which could cause memory leaks or invalid state taken over
to later.
Also the stop() vfunc, or anything called until it from another thread,
might want to be able to use the fields that were just resetted and
become confused because of that.
In the decoder we already had a workaround for things like this happening,
this workaround is not needed anymore.
The implementation of that vfunc might want to use the object lock for
something too. It's generally not a good idea to keep the object lock while
calling any function implemented elsewhere.
Also the ringbuffer can only be NULL at this point, remove a useless if block.
And in the sink actually hold the object lock while setting the ringbuffer on
the instance. Code accessing this is expected to use the object lock, so do it
here ourselves too.
Allows subclasses to do custom caps query replies.
Also exposes the standard caps query handler so subclasses can just
extend on top of it instead of reimplementing the caps query proxying.
Allows decoders to proxy downstream restrictions on caps.
Also implements accept-caps query to prevent regressions caused by the
new fields on the return of a caps query that would cause the accept-caps
to fail as it uses subset caps comparisons
Allows subclasses to do custom caps query replies.
Also exposes the standard caps query handler so subclasses can just
extend on top of it instead of reimplementing the caps query proxying.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
With the new caps query results the caps returned might have extra fields
that are not required by the decoder (framerate for image decoders) and it
causes a regression making, for example, jpegdec reject caps that don't
have framerates.
The accept-caps implementation will do 2 checks:
1) Do subset check with the template caps, making sure all the required
fields that are present on the template are present on the received caps.
2) Do a intersection check with the result of a caps query, making sure
that downstream can accept the fields in the received caps.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
Refactor the encoder's caps query proxying function to a common place
and use it in the videodecoder to proxy downstream restrictions.
The new function is private to the gstvideo lib.
https://bugzilla.gnome.org/show_bug.cgi?id=741263
Update the new buffer size after alignment in the pool configuration
before calling the parent set_config. This ensures that the parent knows
about the buffer size that we will allocate and makes the size check
work in the release_buffer method.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741420
The set_format vfunc does not pass ownership of the caps
to the decoder, so we mustn't unref the caps there.
gst_event_new_caps() does not take ownership of the caps
passed, so we must unref the caps afterwards.
Fixes leaks when running test in valgrind in 1.4 branch.
This reverts commit 406f32a946.
The problem was apparently that my video-orc.h was not updated and did not
include the prototype for that function. Only a "make clean" caused it to
be regenerated.
Create a function to do the pad cleanup of the GstSourceCombine struct
and use it to not forget to also cleanup the sink pad and fix a memory
leak.
https://bugzilla.gnome.org/show_bug.cgi?id=741198
