When we are using a dedicated thread to run the main run loop we
must make sure that all selectors are performed on this same thread.
For instance if performSelectorOnMainThread is called from the real
main thread, it will not go through the message queue and will be
executed from the real main thread. By forcing the target thread,
we ensure that all functions will be called either from the real
main thread when the main run loop is running or from our thread
spinning the main loop.
Add a little hack to run the cocoa main runloop from a separate thread _when_
the main runloop is not being run (which means that the app doesn't use cocoa).
Runloops are thread specific, so the hack boils down to getting the runloop for
the main thread and setting it as the runloop for our dedicated thread.
demux->common.segment is populated during seek handling with the target
start/stop positions. Don't override them when sending out a NEWSEGMENT.
Conflicts:
gst/matroska/matroska-demux.c
If there are no profile restrictions downstream, return caps with
profile=constrained-baseline in the first structure and append
unrestricted caps as the last structure.
Fixes bug #672019
Setting GST_SEEK_FLAG_SKIP when sending a seek event in rtspsrc should
set the "Scale" field in the rtsp PLAY header.
Because the boolean "src->skip" is set after the call, "Speed" instead
of "Scale" is always set. Move the assignment before issuing the _play
request.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=676618
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.
