If we have an upstream GST_EVENT_STREAM_START, use that one instead
of creating a new one which could be completely different from the
upstream one and drop information (like the stream flags and stream
object).
Only create a new event if we don't already have one from upstream
https://bugzilla.gnome.org/show_bug.cgi?id=797215
Ensure that nothing is in any of the streaming thread functions
anymore when going from PAUSED to READY. While the parent's state change
function has deactivated all pads, there is nothing preventing
downstream from activating our srcpad again and calling the getrange()
function. Although we're in READY!
https://bugzilla.gnome.org/show_bug.cgi?id=775687
By default we'll wait for a certain amount of data before
attempting typefinding. However, if the stream is fairly
short, we might get EOS before we ever attempted any
typefinding, so at this point we should force typefinding
and output any pending data if we manage to detect the
type.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
In 0.10 the source pad was a dynamic pad that was only added once
the type had been detected, but in 1.x it's an always source pad,
so checking whether it's still NULL won't work to detect if the
type has been detected.
Makes tagdemux error out when we get EOS but haven't managed to
identify the format of the data after the tag.
https://bugzilla.gnome.org//show_bug.cgi?id=768178
gst_buffer_copy_region() does not copy the duration if it doesn't start
with the first byte. We just skip the tag here, so the duration is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767791
gst_buffer_copy_region() does not copy the timestamp if it doesn't start
with the first byte. We just skip the tag here, so the timestamp is still
valid.
https://bugzilla.gnome.org/show_bug.cgi?id=767173
Otherwise upstream can get confused about offsets as there will
be a jump once the tags have been parsed due to the stripped area.
If upstream pulls from 0 to 100, and then tagdemux does the
tag reading and finds out that the first 200 bytes are the tag, the
next pull from upstream will have an offset of 200 bytes. So
upstream will get the following data:
0 - 100, 300 - (EOS), as it will continue requesting from where
it has last stopped, but tagdemux will add an offset to skip the
tags.
This patch makes sure that the tags have been parsed and skipped
since the first pull range call.
https://bugzilla.gnome.org/show_bug.cgi?id=744580
Accumulate buffers in an adapter instead of appending them because append causes
a lot of memcpys.
Keep track of the last tagsize and accumulate enough data before attempting to
parse more data.
This patch implements a minimal amount of changes in order to not change the
behaviour. We should really rewrite the tag handling and trimming using
the adapter API instead of merging and trimming into a buffer.
Fix reading of tags for the case filsrc ! footagdemux ! fooparse ! ..
where we would not read the tags because we never start our own
streaming thread.
https://bugzilla.gnome.org/show_bug.cgi?id=673185
Originally decodebin couldn't deal with that in 0.10, but now simply
setting the caps when we know them should be enough. Pad activation
mode switching might need some more testing/tweaking with the new
arrangement.
