GstCollectPads2 locking was changed from GstCollectPads to use
the stream lock instead of the object lock for those cases, so
change it so here as well to match.
https://bugzilla.gnome.org/show_bug.cgi?id=666379
Doing dynamic pipelines is hard in 0.10. As we don't have the sticky events in
0.10 and sending such events in special elements like adder and tee was outvoted
on last attempt, be graceful to the misbehaviour instead.
Remove the _ in front of the endianness prefix.
Remove the _3 postfix for the 24 bits formats.
Add a _32 postfix after the formats that occupy extra space beyond their
natural size.
The result is that the GST_AUDIO_NE() macro can simply append the endianness
after all formats and that we only specify a different sample width when it is
different from the natural size of the sample. This makes things more consistent
and follows the pulseaudio conventions instead of the alsa ones.
Rework the audio caps similar to the video caps. Remove
width/depth/endianness/signed fields and replace with a simple string
format and media type audio/x-raw.
Create a GstAudioInfo and some helper methods to parse caps.
Remove duplicate code from the ringbuffer and replace with audio info.
Use AudioInfo in the base audio filter class.
Port elements to new API.
Use atomic ops on pending flags. Rename the segment_pending to
new_segment_pending. Set new_segment_pending not when we received seek, but
when we received the first upstream new_segment.
Send FLUSH_STOP right after forwarding the seek event upstream if necessary.
This makes sure that adder->srcpad is not left flushing if seeking fails or if
upstream is blocked.
The same fix was already applied to videomixer in 49b2a946.
Adder was using always incrementing timestamps. Seeking was done by setting the
position in the newsegment event. This was failing when doing segmented seeks
with rate<0.0, as offset (and thus timestamp) would go below 0.
Now we take both cur and end from the seek event. We construct newsegment events
depending including cur and end from the seek event. We set position to the
start of the segment. Timestamp is set to start or end of segment depending on
rate. Offset is recalculated.
Decrement sample counter when playing backwards. Set proper segment when playing
backwards (0..cur instead or cur..-1). Add more logging and fix a format string.
Detect EOS faster.
Try to reuse one of the input buffer as the output buffer. This usually works
and avoids an allocation and a memcpy.
Be smarter with GAP buffers so that they don't get mixed or cleared at all. Also
try to use a GAP buffer as the output buffer when all input buffers are GAP
buffers.
There's not much point in using GST_DEBUG_FUNCPTR with GObject
virtual functions such as get_property, set_propery, finalize and
dispose, since they'll never be used by anyone anyway. Saves a
few bytes and possibly a sixteenth of a polar bear.
Also use the capsfilter if there is no src-peer as the caps constrain what
we can do. Don't create any_caps as a default, as we check for NULL to skip the
filtering. This is a (small) performance regression as we always intersect
otherwise.
Adder can only handle one common format accross the pads. Thus one needed to add
a capsfilter afterwards and manage the caps. Now one can simply set the caps on
the property.
This ensures that collectpads' cookie is properly updated so that when the streaming
threads will restart and be checking for the flushing status of all pads there will
be no inconsistent state.
When a seek failed upstream, make sure the adder sinkpad is set unflushing again
so that streaming can continue.
We only have a pending segment when we flushed.
Set the flush_stop_pending flag inside the appropriate locks and before we
attempt to perform the upstream seek.
Add some more comments.
Use the right lock to protect the flags in flush_stop.
See #585708
At least do the fix to sent the flush_stop when seeking failed to ensure we
keep no pads flushing. before it was send when the seeking worked which is just
plain wrong and was not the intention.
When no flush-stop has been sent by upstream, we have to send one ourselves to
continue playback. Do this as soon as the collect function is called instead of
after we possibly pushed segment events (that got then flushed out)
Adder was relying that something else sends a flush stop. When using adder with
a livesource it was not getting a flush_stop and thus all pads downstream where
keept flushing. Mark a pending flush_stop and send it when we are working on
the new segment back in the streaming thread.
Original commit message from CVS:
* gst/adder/Makefile.am:
* gst/adder/gstadder.c:
Cleanup variable names to make the adder-loop easier to understand.
Also try to use liboil to spee it up, but ifdef it out as it does not
make any change for me (Intel pentim M (sse,sse2) please try on other
systems).
