The processing deadline is the acceptable amount of time to process the media
in a live pipeline before it reaches the sink. This is on top of the algorithmic
latency that is normally reported by the latency query. This should make
pipelines such as "v4lsrc ! xvimagesink" not claim that all frames are late
in the QoS events. Ideally, this should replace max_lateness for most applications.
https://bugzilla.gnome.org/show_bug.cgi?id=640610
Position queries with GST_FORMAT_TIME are supposed to return stream
time.
gst_base_sink_get_position() estimates the current stream time on its
own instead of using gst_segment_to_stream_time(), but the algorithm
used was not taking segment.offset into account, resulting in invalid
values when this field was set to a non-zero value.
https://bugzilla.gnome.org/show_bug.cgi?id=792434
buffer is not unreferened if preroll failed
:Detailed Notes:
- Problem : video freeze when switching from pause to 1/2-FF repeatedly
- RootCause : buffer leaks in basesink
- Solution : unref the buffer if prerolled failed
:Testing Preformed:
How to Test :
pause -> 1/2 FF -> resume -> pause -> 1/2 FF ...
https://bugzilla.gnome.org/show_bug.cgi?id=784932
This was totally non-obvious, the kind of big problem is that subclasses must
be able to unblock their streaming thread and continue exactly where they left off
on unpause!
https://bugzilla.gnome.org/show_bug.cgi?id=773912
This is cosmetic as 'late' should never be set during preroll (in pause).
Though code may evolve in the future, so this is good for preventing
potential bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=772468
When the first buffer arrives, we endup calling:
->prepare()
->prepare()
->preroll()
->render()
This will likely confuse any element using this method. With this patch,
we ensure the preroll take place before the first render prepare() is
called. This will result in:
->prepare()
->preroll()
->prepare()
->render()
https://bugzilla.gnome.org/show_bug.cgi?id=772468
Implement handling in basesink to not unconditionally discard
out-of-segment buffers and expose it as a new property on fakesink
(not unconditionally in all basesink based sinks).
The property defaults to FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=765734
The durations of the buffers are (usually) assuming that no frames are being
dropped and are just the durations coming from the stream. However if we do
trickmodes, frames are being dropped regularly especially if only key units
are supposed to be played.
Fixes completely bogus QoS proportion values in the above case.
If we were in PAUSED, the current clock time and base time don't have much to
do with the running time anymore as the clock might have advanced while we
were PAUSED. The system clock does that for example, audio clocks often don't.
Updating the start time in PAUSED will cause a) the wrong position to be
reported, b) step events to step not just the requested amount but the amount
of time we spent in PAUSED. The start time should only ever be updated when
going from PLAYING to PAUSED to remember the current running time (to be able
to compensate later when going to PLAYING for the clock time advancing while
PAUSED), not when we are already in PAUSED.
Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com>
The updating of the start time when the state is lost was added in commit
ba943a82c0 to fix the position reporting when
the state is lost. This still works correctly after this change.
https://bugzilla.gnome.org/show_bug.cgi?id=739289
The subclass should do that already, but just in case do it ourselves too as a
fallback. Without this, e.g. playbin will just wait forever if this fails
because it is triggered as part of an ASYNC state change.
It is calling do_sync(), which requires the STREAM_LOCK and PREROLL_LOCK to be
taken. The STREAM_LOCK is already taken in all callers, the PREROLL_LOCK not.
https://bugzilla.gnome.org/show_bug.cgi?id=764939
gst_segment_to_position might cause confusion, especially with the addition of
gst_segment_position_from_stream_time . Deprecated gst_segment_to_position
now, and replaced it with gst_segment_position_from_running_time.
Also added unit tests.
As of now, even for stream completly inside segment, there is no
guarantied that the DTS will be inside the segment. Specifically
for H.264 with B-Frames, the first few frames often have DTS that
are before the segment.
Instead of using the sync timestamp to clip out of segment buffer,
take the duration from the start/stop provided by the sub-class, and
check if the pts and pts_end is out of segment.
https://bugzilla.gnome.org/show_bug.cgi?id=752791
In basesink functions gst_base_sink_chain_unlocked(), below code is used to
checking if buffer is late before doing prepare call to save some effort:
if (syncable && do_sync)
late =
gst_base_sink_is_too_late (basesink, obj, rstart, rstop,
GST_CLOCK_EARLY, 0, FALSE);
if (G_UNLIKELY (late))
goto dropped;
But this code has problem, it should calculate jitter based on current media
clock, rather than just passing 0. I found it will drop all the frames when
rewind in slow speed, such as -2X.
https://bugzilla.gnome.org/show_bug.cgi?id=749258
Allows buffers to be reclaimed when caps is to be renegotiated so
that bufferpools can be stopped. As the allocation query is
serialized all buffers have been already drained from the pipeline,
except this last_sample one.
https://bugzilla.gnome.org/show_bug.cgi?id=682770
Use gst_buffer_copy_deep() to force the copy of the underlying
memory instead of possibly doing a shallow copy of the buffer
and just referencing the memory
https://bugzilla.gnome.org/show_bug.cgi?id=745287
Based on patch from Song Bing <b06498@freescale.com>
Don't just set the need_preroll flag to TRUE in all cases. When we
are already prerolled it needs to be set to FALSE and when we go to
READY we should not touch it. We should only set it to TRUE in other
cases, like what the code above does.
See https://bugzilla.gnome.org/show_bug.cgi?id=736655
When using a negative rate (rate being segment.rate * segment.applied_rate),
we will end up reporting decreasing positions, therefore adjust the clamping
against last reported value accordingly.
Fixes positions getting properly reported with applied_rate < 0.0
https://bugzilla.gnome.org/show_bug.cgi?id=738092
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.
Currently we are just returning FALSE, but we do have the information
we should just answer the query the same way as when answering through
the GstElement.query vmethod default implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=739580
