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>
