Writing a test for unscheduling the gst_clock_id_wait inside the
identity element, found an invalid read, caused by removing the clock-id
when calling _unschedule instead of letting the code calling _wait remove
the clock-id after being unscheduled.
https://bugzilla.gnome.org/show_bug.cgi?id=752055
Microoptimisation: Let GstQueueArray store our
item struct. That way we don't have to alloc/free
temporary QueueItem slices for every item we want
to put into the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=750149
Have all sections in alphabetical order. Also make the macro order consistent.
This is a preparation for generating the file. Remove GET_CLASS macro for
typefine element, since it is not used and the header is not installed.
event can't be NULL, it has been dereferenced by GST_EVENT_TYPE (), and no
case frees the pointer. Remove unnecessary check which will always be True.
CID #1308955
This disables the segment.base adjustments, which is useful if downstream
takes care of base adjustments already (example: a combination of concat
and streamsynchronizer)
https://bugzilla.gnome.org/show_bug.cgi?id=751047
If we receive more than UIO_MAXIOV (1024 typically) buffers
in a single writev call, fall back to consolidating them
into one output buffer or multiple write calls.
This could be made more optimal, but let's wait until it's
ever a bottleneck for someone
If the reset_time value of a FLUSH_STOP event is set to TRUE, the pipeline
will have the base_time of its elements reset. This means that the concat
element's current_start_offset has to be reset to 0, since it was
calculated with the old base-time in mind.
Only FLUSH_STOP events coming from the active pad are looked at.
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Subsequent EOS will push on the source pad that already received
EOS and that will make the event function return FALSE. It needs
only to push the first one and only return TRUE for the subsequent
ones.
The gst_object_unref() in the block above may be dropping
the last ref to the pad and free the pad. Set pad pointer
to NULL here, so that we don't accidentally use a
possibly-freed pad pointer in the debug log statements
further below, and also use the tee element as log object
since that's more appropriate anyway.
Fixes valgrind warnings and crashes in tee test_stress
unit test when debug logging is enabled.
gst_type_find_element_src_event() is supposed to consume @event but wasn't
doing so when it was handling the event itself.
https://bugzilla.gnome.org/show_bug.cgi?id=747775
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
There is no reason I can see to set mq->buffering = TRUE when
use_buffering is set; the code here also calls update_buffering(), which
will set mq->buffering = TRUE if this is warranted because of low buffer
levels.
https://bugzilla.gnome.org/show_bug.cgi?id=745937
gst_selector_pad_chain() was popping cached buffers out of the queue without
freeing those. Make sure we don't steal the GstBuffer as the cached buffer ref
has been passed to the pad chain function.
This can be reproduced by running the
validate.file.playback.switch_subtitle_track_while_paused.test5_mkv scenario
with Valgrind.
https://bugzilla.gnome.org/show_bug.cgi?id=747611
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
This property avoids not linked error when all the pads are unlinked
or when there are no source pads. This is useful in dynamic pipelines
where it can happen that for a short time there are no pads at all or
all downstream pads are not linked yet.
https://bugzilla.gnome.org/show_bug.cgi?id=746436
When determining whether the running_time of a pad can be
calculated, check if the segment is in TIME format instead
of using the 'active' field.
Since the latter is set through *any* activity, it's not a
reliable indicator of segment presence.
https://bugzilla.gnome.org/show_bug.cgi?id=739620
With the disappearance of the 'block' signal, this
flag cannot be set to TRUE.
gst_input_selector_wait disappears as it never waits
and just returns self->flushing.
https://bugzilla.gnome.org/show_bug.cgi?id=736891
This signal blocks the input-selector with no means of unblocking
other than a state change back to READY. It seems this signal was
part of an old way of synchronously switching the selector,
together with the already-removed 'switch' signal.
Removing the signal is safe, as attempting to use it could only
end in deadlocks. Attempting to emit an unknown signal just causes
g_criticals.
https://bugzilla.gnome.org/show_bug.cgi?id=736891
