Consider a downstream element that may issue seeks in very short
succession (e.g. queue2), depending on the access pattern of
the downstream element (e.g. qtdemux with audio/video chunks
interleaved so that there's always a sizeable gap between the
current chunks for each stream). In this case, queue2 will maintain
two ranges, and even when it serves a chunk from memory, it will
switch ranges and make souphttpsrc seek to the end of the available
data for that range, assuming that that's where we'll want to
continue reading from next.
This may lead to the following seek request pattern:
- source reading position A
- seek to B
- now reading position still A, requested_postion is B
- streaming thread to be restarted to continue from B
- seek to A, before streaming thread had time to do the seek
- do_seek() now sees reading position == seek position and
returns early.
- however, requested position is still B from the earlier
seek request
- streaming thread starts up, sees that a seek to B is pending
and requests data from B from the server, while the GstBaseSrc
segment has of course been updated/reset to position A, which
was the last seek request.
- we will now send data for position B and pretend that's the
data from position A (via the newsegment event, etc.)
- this causes data corruption
Reproducible doing seek-emulated fast-forward/backward on 006648.
This never really took off and is most likely completely
unused. If there is still a need for this, it should
probably be done differently, perhaps inside oggdemux/mux.
input.std is of type v4l2_std_id which is defined as 64-bit unsigned integer.
Casting to uint means the higher bits, wich are used for the private video
standards of the TI video capture/display driver for example, are lost.
Downstream likely won't accept video/x-raw and the caps query
will return EMPTY caps. Instead, create a copy of the caps that
has all structure names replaced by 'image/jpeg'
Simple pipeline that shows the problem:
gst-launch-1.0 videotestsrc num-buffers=1 ! "video/x-raw, \
width=(int)640, height=(int)480" ! videoscale ! jpegenc ! \
"image/jpeg, width=(int)800, height=(int)600" ! filesink \
location=/tmp/image.jpg
This fixes a not-negotiated error at least on mov files with
twos audio with two channels and video dvcp. As playbin and gst-launch
sample coming from the qtdemux.c file uses audioconvert and the latter
require format interleaved.
https://bugzilla.gnome.org/show_bug.cgi?id=675326
When all pads go to EOS immediately, we are not negotiated and our collected
function is called (without any available data). Handle this case gracefully.
Conflicts:
gst/interleave/interleave.c
