Make a method to get the seeking threshold. If data is further away from
this threshold we want to perform a seek upstream.
When the current downloaded range can merge with the next range,
actually include the data of the next range into the current range
instead of discarding it. Also decide if we seek to the write position
of the merged range or continue reading.
Don't set the size to -1 in automatic_eos mode (which also updates the
duration to -1). We only want automatic_eos mode influence the maxsize
calculations without any side effects.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724564
Using info from gst-plugins-base/docs/design .
Encoded streams might make use of the raw properties, so list them all under foo/* .
For foo/raw, only note which of these properties are mandatory.
I didn't take a closer look at the raw formats yet. Those might still be out-of-date.
https://bugzilla.gnome.org/show_bug.cgi?id=724187
This defaults to TRUE and if it is set to FALSE it is the subclasses
responsibility to return GST_FLOW_EOS from the create() vmethod once
the stream is done.
Use the technique that is now done in GTK+ so that the plugins do not have
to be installed in c:\gstreamer\lib\<debug>\gstreamer-$(GSTApiVersion),
but can be installed in
<parent_folder_of_gstreamer_main_dll>\lib\<debug>\gstreamer-$(GSTApiVersion),
or as per g_win32_get_package_installation_directory_of_module() allows.
https://bugzilla.gnome.org/show_bug.cgi?id=679115
... instead of returning a reference to a global instance. The caller might
want to change the global instance otherwise, which causes funny effects like
all global instances being changed and at the same time nothing in the caps
being changed.
As the caps might be immutable while we do this we have to do some magic
with atomic operations.
https://bugzilla.gnome.org/show_bug.cgi?id=723236
If the segment event is allowed to be pushed to all pads it
will lead to an assertion of 'sticky event misordering:
segment received before caps' in case the pad-negotiation-mode
is set to 'active' or 'none'.
This patch fixes this by making all sticky events follow the
property like the caps event to prevent misordering warnings.
When a new pad is activated the current sticky events on the
sinkpad are forwarded to it in the proper order.
https://bugzilla.gnome.org/show_bug.cgi?id=723266
Keep an extra write ref on the control socket. This ensures that we
avoid a read/write on the socket when going from non-empty->empty->not-empty.
We remove the write ref only when we actually are empty and we need to
wait for flushing or a new buffer.
This makes the bufferpool benchmark about 30% faster than the pure
malloc implementation.
When the single queue size was just bumped by 1 to allow more buffers to
be added, the buffers limit could be reduced to the current level when
setting the max-size-buffers property. This would result in a stall
since the queue would not grow anymore at this point.
Prevent this by not reducing a single queue size below the current
number of buffers + 1.
https://bugzilla.gnome.org/show_bug.cgi?id=712597
Store the eos event seqnum and use it when creating the
new eos event to be pushed downstream. To know if the eos
was caused by the eos events received on send_event, a
'forced_eos' flag is used to use the correct seqnum on
the event pushed downstream.
Useful if the application wants to check if the EOS message
was generated from its own pushed EOS or from another source
(stream really finished).
Also adds a test for this
https://bugzilla.gnome.org/show_bug.cgi?id=722791
