This is documented as:
> you can query how many buffers are queued by reading the
> #gstqueue:current-level-buffers property. you can track changes
> by connecting to the notify::current-level-buffers signal (which
> like all signals will be emitted from the streaming thread). the same
> applies to the #gstqueue:current-level-time and
> #gstqueue:current-level-bytes properties.
... but was not implemented.
This also respects the `notify::silent` property for the notify signals
to be less intrusive.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7486>
If the first buffers have no timestamp then the sink position would be
initialized to 0. The source pad might output this buffer, which would then
initialize the source position to 0 too.
Afterwards two buffers with a valid but huge timestamp might arrive before any
of them are output on the source pad. The first one would set the sink position
to a huge value, the second one would notice that the difference between the
huge value and 0 is certainly larger than max-size-time and consider the queue
as full.
Instead, simply don't update the times from buffers without timestamps and
assume whatever was set before is still valid, i.e. the buffer has the same
timestamp as the previous one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7071>
Do not update timelevel on segment. Segment itself does not tell
anything about the amount of buffered time duration in the element
but buffer timestamp/duration is required to measure actual bufferred time.
Moreover, at the time when new segment is applied to sink/srcpad,
segment.position would point to random value.
Therefore calculating running time using the random value does not
make sense and it will result in wrong timelevel report.
This patch updates queue/queue2's timelevel measuring logic so that
it can be updated only on buffer/buffer-list/gap-event flow.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5430>
This is to fix an infinitely blocked upstream streaming thread if
* upstream has fixed-size buffer pool, some H/W decoders for example
* downstream returned flow error without releasing buffer
When the fixed-size buffer pool hits its configured max-buffers and
also downstream of queue returned flow error without releasing corresponding
buffer, upstream has no chance to run the next processing loop
because it will be blocked by acquire_buffer(), and therefore
downstream flow will not be propagated to upstream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5023>
GLib guarantees libintl is always present, using proxy-libintl as
last resort. There is no need to mock gettex API any more.
This fix static build on Windows because G_INTL_STATIC_COMPILATION must
be defined before including libintl.h, and glib does it for us as part
as including glib.h.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2028>
