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
Instead of re-sending sticky events over and over to a not-linked
pad, mark them as sent the first time. If the not-linked came from
downstream, it already received the events. If the pad is actually
not-linked, the sticky events will be rescheduled when the
pad is linked anyway.
There is a similar explanation in gst_caps_make_writable, but the existing
documentation can be misleading since it does not define what 'is already
writable' means.
Also note when this function is meant to be used.
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
API: GST_BUFFER_DTS_OR_PTS
Many scenarios/elements require dealing with streams of buffers that
might have DTS set (i.e. encoded data, potentially reordered)
To simplify getting the increasing "timestamp" of those buffers, create
a macro that will return the DTS if valid, and if not the PTS
They take a GstBaseSink instance as argument at not a GstPad. Rename the
argument to 'obj' which is not miss leading and in line with
GST_BASE_SINK_PAD(obj).
https://bugzilla.gnome.org/show_bug.cgi?id=756954
Updated gst_segment_position_from_stream_time and gst_segment_to_stream_time to reflect correct calculations for the case when the applied rate is negative.
Pasting from design docs:
===============================
Stream time is calculated using the buffer times and the preceding SEGMENT
event as follows:
stream_time = (B.timestamp - S.start) * ABS (S.applied_rate) + S.time
For negative rates, B.timestamp will go backwards from S.stop to S.start,
making the stream time go backwards.
===============================
Therefore, the calculation for applied_rate < 0 should be:
stream_time = (S.stop - B.timestamp) * ABS (S.applied_rate) + S.time
and the reverse:
B.timestamp = S.stop - (stream_time - S.time) / ABS (S.applied_rate)
https://bugzilla.gnome.org/show_bug.cgi?id=756810
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
An ASYNC READY->PAUSED might have failed without the bin code noticing during
the state change, in which case we will never get PAUSED->READY and would leak
messages.
https://bugzilla.gnome.org/show_bug.cgi?id=756611
In file included from gst-ptp-helper.c:40:0:
/usr/include/net/if.h:265:19: error: field 'ifru_addr' has incomplete type
struct sockaddr ifru_addr;
https://bugzilla.gnome.org/show_bug.cgi?id=756136
