This makes sure that SEEK events are sent to all upstream elements, which is
required if different streams are completely distinct pipeline parts. Also this
allows QoS to be done on deselected streams, flushes to be handled correctly,
etc.
The switch action signal with the stop and start running times
is not necessary anymore. Closing of segments is not necessary
and adjusting the start running time of a segment can later be
done with new GstPad API.
This reverts commit cf4fbc005c.
This change did not improve the situation for bindings because
queries are usually created, then directly passed to a function
and not stored elsewhere, and the writability problem with
miniobjects usually happens with buffers or caps instead.
Improve GstSegment, rename some fields. The idea is to have the GstSegment
structure represent the timing structure of the buffers as they are generated by
the source or demuxer element.
gst_segment_set_seek() -> gst_segment_do_seek()
Rename the NEWSEGMENT event to SEGMENT.
Make parsing of the SEGMENT event into a GstSegment structure.
Pass a GstSegment structure when making a new SEGMENT event. This allows us to
pass the timing info directly to the next element. No accumulation is needed in
the receiving element, all the info is inside the element.
Remove gst_segment_set_newsegment(): This function as used to accumulate
segments received from upstream, which is now not needed anymore because the
segment event contains the complete timing information.
This reverts commit 9ef1346b1f.
Way to much for one commit and I'm not sure we want to get rid of the pad caps
just like that. It's nice to have the buffer and its type in onw nice bundle
without having to drag the complete context with it.
Remove pad_alloc and all references. This can now be done more efficiently and
more flexible with the ALLOCATION query and the bufferpool objects. There is no
reverse negotiation yet but that will be done with an event later.
1) We need to lock and get a strong ref to the parent, if still there.
2) If it has gone away, we need to handle that gracefully.
This is necessary in order to safely modify a running pipeline. Has been
observed when a streaming thread is doing a buffer_alloc() while an
application thread sends an event on a pad further downstream, and from
within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing
while the streaming thread has its buffer_alloc() in progress.
It can happen that the currently active pad got the EOS event
before it was activated and the previously active pad got the
EOS event after it was deactivated. In that case we have to
send the EOS event from an inactive pad downstream.
This makes sure that during switches at no point in time all pads
have returned not-linked, which can happen when playing an audio-only
file with playbin2 and switching between the streams for example.
Fixes bug #644935.
