Without this, we risked:
* Checking the flushing state on an unexisting list
* Not setting the flushing state on pads that had just been added
Partially fixes#590056
Return FALSE in basesrc's default query handler when we get a SEEKING query for
a format that's not the one the source operates in. Previously (ie. before, in
the git version) we would return TRUE in that case and seekable=FALSE, which
is more correct, but causes backwards compatibility problems. (Before that
we would change the format of the query when answering, which was completely
broken since callers don't expect that or check for it). Since the SEEKING
query is a fairly recent addition, not all demuxers, parsers and decoders
implement it yet, in which case any SEEKING query by an application will
just be passed upstream where it will then be handled by basesrc. Now, if
e.g. totem does a SEEKING query for TIME format and we have a demuxer that
doesn't implement the query, basesrc would answer it with seekable=FALSE in
most cases, and totem can only take that as authoritative answer, not knowing
that the demuxer doesn't implement the SEEKING query. To avoid this, we make
basesrc return FALSE to SEEKING queries in unhandled formats. That way
applications like totem can fall back on assuming seekability depending on
whether a duration is available, or somesuch. Downstream elements doing
such queries are likely to equate an unhandled query with a non-seekable
response as well, so this should be an acceptable fix for the time being.
See #584838, #588944, #589423 and #589424.
Clarify byte reader docs a bit: offset is relative to the current
position of the reader, not to the start of the data. Also, the
examples in both the adapter docs and the byte reader docs have
the mask and pattern arguments swapped (see #587561). Spotted
by Carl-Anton Ingmarsson.
Add a pattern scan function similar to the one recently added to
GstAdapter, and a unit test (based on the adapter one).
Fixes#585592.
API: add gst_byte_reader_masked_scan_uint32()
Update design doc with step-start docs.
Add eos field to step done message
when stepping in reverse, update the segment time field.
Flush out the current step when we are flushing.
When we start stepping, store the start/stop values of the segment before we
install new start/stop values for clipping in non-flushing steps.
for non-flushing steps, update the element start time. For flushing steps, it
does not change because running_time does not advance
Make sure we always perform the stop_stepping operations even when we drop
frames.
Note in the docs that a flushing step in PLAYING brings the pipeline to the lost
state and skips the data before prerolling again.
Implement the flushing step correctly by invalidating the current step
operation, which would activate the new step operation.
When a subclass is blocking in _wait_preroll() in the _render method, make sure
we can unlock the subclass and detect this return value from the render method.
Update framestep document, we want to pass the flush flag in the step-done
message.
Add flush flag to the gstmessage.
Update examples to use the new step-done message api.
Implement framestep with playback rates < 0.0 too.
