Sometimes filesink cleanup during stop may fail due to fclose error.
In this case object left partial cleanup with no file opened
but still holding old file descriptor.
It's not possible to change location property in a such state,
so next start will cause old file overwrite if 'append' does not set.
According to man page and POSIX standard about fclose behavior(extract):
------------------------------------------------------------------------
The fclose() function shall cause the stream pointed to by stream
to be flushed and the associated file to be closed.
...
Whether or not the call succeeds, the stream shall be disassociated
from the file and any buffer set by the setbuf() or setvbuf()
function shall be disassociated from the stream.
...
The fclose() function shall perform the equivalent of a close()
on the file descriptor that is associated with the stream
pointed to by stream.
After the call to fclose(), any use of stream results
in undefined behavior.
------------------------------------------------------------------------
So file is in 'closed' state no matter if fclose succeed or not.
And cleanup could be continued.
https://bugzilla.gnome.org/show_bug.cgi?id=757596
The input of queue/queue2 might have DTS set, in which cas we want
to take that into account (instead of the PTS) to calculate position
and queue levels.
https://bugzilla.gnome.org/show_bug.cgi?id=756507
In order to accurately determine the amount (in time) of data
travelling in queues, we should use an increasing value.
If buffers are encoded and potentially reordered, we should be
using their DTS (increasing) and not PTS (reordered)
https://bugzilla.gnome.org/show_bug.cgi?id=756507
Previously this code was just blindly setting the cached flow return
of downstream to GST_FLOW_OK when we get a SEGMENT.
The problem is that this can not be done blindly. If downstream was
not linked, the corresponding sinqlequeue source pad thread might be
waiting for the next ID to be woken up upon.
By blindly setting the cached return value to GST_FLOW_OK, and if that
stream was the only one that was NOT_LINKED, then the next time we
check (from any other thread) to see if we need to wake up a source pad
thread ... we won't even try, because none of the cached flow return
are equal to GST_FLOW_NOT_LINKED.
This would result in that thread never being woken up
https://bugzilla.gnome.org/show_bug.cgi?id=756645
This way one can define new tracing probes without changing the core. We are
using our own quark table, as 1) we only want to initialize them if we're
tracing, 2) we want to share them with the tracers.
Instead of a single invoke() function and a 'mask', register to individual
hooks. This avoids one level of indirection and allows us to remove the
hook enums. The message enms are now renamed to hook enums.
Get the number of cpus and scale process cpu-load accordingly. Switch the
cpuload to be per-mille to get smoother graphs. Add a bit more logging and use
the _OBJECT variant.
Keep tracer base class in tracer and move core support into the utils module.
Add a unstable-api guard to the tracer.h so that external modules would need to
acknowledge the status by setting GST_USE_UNSTABLE_API.
Iterator may need to be resynced, for instance if pads are released
during state change.
got_eos should be protected by the object lock of the element, not of
the pad, as is the case throughout the rest of the funnel code.
https://bugzilla.gnome.org/show_bug.cgi?id=755343
After doing gst_pad_push() in case of sync_streams and cache_buffers,
if the buffer can not be kept in cache, it should be unreffed to avoid
memory leackage.
https://bugzilla.gnome.org/show_bug.cgi?id=755141
This caused problems with oggdemux when queue2 was
operating in queue mode and the souphttpsrc upstream
is not seekable because the server doesn't support
range requests. It would then still claim seekability
and then things go wrong from there.
This reverts commit 7b0b93dafe.
https://bugzilla.gnome.org/show_bug.cgi?id=753887
upstream_size can be negative but queue->upstream_size is unsigned type.
to get a chance to update queue->upstream_size in gst_queue2_get_range()
it should keep the default value.
https://bugzilla.gnome.org/show_bug.cgi?id=753011
Resetting the flushing state of the pads at the end of the
PAUSED_TO_READY transition will make pads handle serialized
queries again which will wait for non-active pads and might
cause deadlocks when stopping the pipeline.
Move the reset to the READY_TO_PAUSED instead.
https://bugzilla.gnome.org/show_bug.cgi?id=752623
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
This apparently got broken by bc1ec4e. Since self->blocked is always
FALSE, gst_input_selector_wait never actually waits.
Using (!self->eos || self->blocked) && ... as the loop condition would
be incorrect as well, because then the other call to the function in
_chain would block until EOS, so the functions cannot be merged trivially.
Since blocking is obsolete, gst_input_selector_wait will get removed anyway.
As such, just inline the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=746518
Add QUERY_SEEKING handling to queue2, so RTMP live streams become
seekable when a queue2 in download or ringbuffer mode is inserted:
rtmpsrc ! queue2 ! flvdemux
https://bugzilla.gnome.org/show_bug.cgi?id=733351
Otherwise we end up dropping e.g. CAPS queries, and then upstream just
negotiates to whatever format it wants to. Once the valve is not-dropping
anymore this can easily result in negotiation failing completely.
https://bugzilla.gnome.org/show_bug.cgi?id=746448
Demultiplex a stream to multiple source pads based on the stream ids from the
stream-start events. This basically reverses the behaviour of funnel.
https://bugzilla.gnome.org/show_bug.cgi?id=707605
We use the segment format to detect if we run the streaming thread or not.
Without resetting we might believe we do so, although we only did in the past
and are now running in e.g. push mode.
https://bugzilla.gnome.org/show_bug.cgi?id=745073
It might still be waiting for a query to be handled, or the queue to become
empty again for the next item. Also if downstream returns FLUSHING, flush the
queue like we do in queue and multiqueue.
Otherwise we might wait forever for serialized queries to be handled as the
loop function is stopped and as such we will never ever dequeue the query and
handle it.
https://bugzilla.gnome.org/show_bug.cgi?id=745319
... and only unblock when either a) the pad becomes active and the event
should be forwarded or b) the active pad went EOS itself.
Otherwise it can happen that we switch from a longer track that is not EOS yet
to a shorter track that already is EOS, but the shorter track won't have any
possibility to send its EOS event downstream anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=740949
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
