A proxy-pad should always proxy the caps related queries
and events to its down or upstream peers on the other side
of the element. Falling back to a caps query seems wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=754112
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.
gst_segment_position_from_stream_time() will convert stream time into a
position in the segment so that gst_segment_to_stream_time() with that
position returns the same stream time. It will return -1 if the stream time
given is not inside the segment.
When a running-time-offset is stored in the event, it could become smaller
than 0 although the event is otherwise correct. This can happen when pad
offsets are used.
To prevent this, we set the timestamp to -diff, so that in the end the sum of
both is exactly 0.
https://bugzilla.gnome.org/show_bug.cgi?id=754356
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
This fixes a race where a state change may return failure if it has
request pads that are deactivated and removed (and thus have no
parent) at the same time as the element changes state and (de)activates
its pads.
https://bugzilla.gnome.org/show_bug.cgi?id=755342
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
In order for gst_harness_new_full to be MT-safe the increase and
decrease of HARNESS_REF must be MT-safe. This allows for creating
multiple harnesses from different threads wrapping the same element.
https://bugzilla.gnome.org/show_bug.cgi?id=754661
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
1. Get a list of pad templates from the element class, not the
factory. This allows us to interact with test-elements that does
not have a factory.
2. Use the pad_template_caps in caps-queries when caps is not set
explicitly on the pad. Not doing so is simply wrong, and prohibits
interactions with special templates used for testing.
https://bugzilla.gnome.org/show_bug.cgi?id=754193
There exist cases where a reconfigure event was propagated from
downstream, but caps didn't change. In this case, we would
reconfigure only when the next buffer arrives. The problem is that
due to the allocation query being cached, the return query parameters
endup outdated.
In this patch we refactor the reconfigurating code into a function, and
along with reconfiguring when a new buffer comes in, we also reconfigure
when a query allocation arrives.
https://bugzilla.gnome.org/show_bug.cgi?id=753850
As this test is using a short sleep (GST_USECOND, which is 10ms
in microsecond), sometimes that EOS event is received before the
loop in basesrc have run _do_seek() and pushed the update segment.
To solve this issue, we wait for the initial segment (and flush it)
then we wait for the second segment before sending EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=753365
Explicitly keep track again whether upstream tags or parser tags
already contain bitrate information, and only force a tag update
for a bitrate if we are actually going to add the bitrate to the
taglist later. This fixes constant re-sending of the same taglist,
because upstream provided a bitrate already and we didn't add it,
so we didn't save the 'posted' bitrate, which would then in turn
again trigger the 'bitrate has changed too much, update tags'
code path. Fixes tag spam with m4a files for example.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
In 0.10 there were no sticky events, and all tag events
sent would just be merged with the previously-received
tags. In 1.x we have sticky events, and the tags in the
tag event(s) should at all times carry the complete tags,
so we can't just push some tags and then just push tags
with just bitrates to update the bitrates, etc.
Instead we need to keep track of the upstream stream tags
received, of the tags set by the video decoder subclass,
and send an updated tag event with the combined tags
including our own bitrate tags (if applicable) whenever
the upstream tags, the subclass tags or any of our bitrates
change.
https://bugzilla.gnome.org/show_bug.cgi?id=679768
