When removing the current program, it will get freed by the
hash table removal callback, so ensure we clear our pointer
to it.
Fixes a crash later on in gst_ts_demux_push trying to access it.
https://bugzilla.gnome.org/show_bug.cgi?id=656927
http://dvd.sourceforge.net/spu_notes does not mention that high bits
are to be masked, and not clearing them makes a sample work, where
clearing them yielded left > right.
History from the dvdspu plugin, from where this code was copied,
does not shed any light, as tracing this code's origin shows
the same bitmasks being there in 2007 when it was imported.
https://bugzilla.gnome.org/show_bug.cgi?id=657091
http://dvd.sourceforge.net/spu_notes does not mention that high bits
are to be masked, and not clearing them makes a sample work, where
clearing them yielded left > right.
History does not shed any light, as tracing this code's origin shows
the same bitmasks being there in 2007 when it was imported.
https://bugzilla.gnome.org/show_bug.cgi?id=620119
The task function uses GST_TASK_WAIT which does a g_cond_wait giving it
the GST_OBJECT_GET_LOCK of the task. The mutex gets locked when
g_cond_wait returns, so if we don't lock/unlock it, it will
stay locked forever, preventing the task from ever finishing.
We shouldn't lock the task object lock, so let's remove the GST_TASK_WAIT
and make the task pause instead if there are no buffers in the queue.
When a program is changed, stream_added is called which sets the
need_newsegment to TRUE, then stream_removed is called, which calls
the flush_pending_data, which checks for the newsegment and causes
it to send a new-segment.
We must not send the newsegment when flushing the pending data on the
removed stream. We should only push it when flushing data on the newly
added streams (after they finish parsing their PTS header)
If a program/stream is changed, then a newsegment is sent which must
not be the same as the base segment since it happens later. We must
shift the start position by the time elapsed since the newsegment
and the current PTS of the stream
By using a separate variable, first it allows us to sort the lists
of alternates but keep the pointer on the first occurence in the main
playlist (to respect the spec of starting with the bitrate specified
first in the main playlist). It also avoid playing with the lists variable
which should be used to store the list of playlists and not as a pointer
to the current one.
Also fixes a memleak with the g_list_foreach freeing the lists, if it wasn't
pointing to the first element of the list.
Builds with MSVC, not tested in MinGW or anything else. Added
COM handling code, borrowed from dshowvideosink. Moved Linux
specific files to ./linux and added Windows specific files to
./win (generated from IDL files in VS9). Added macros to handle
BSTR and defined bool as BOOL. Fixes#655362.
Signed-off-by: David Schleef <ds@schleef.org>
Basesrc derived classes send an eos when they change state
from paused to ready and that breaks video recordings on camerabin2
as it makes the whole audio branch pads flushing.
Prevent it by using a pad probe that only allows the eos to pass
when it is caused by a stop-capture action.
Adding some additional checks for custom camerabin2 messages
Also improves reliability of the tests by waiting for the preview-buffer message.
This message is generated from the preview pipeline, and might arrive later than the
image/video-done from the main camerabin2 pipeline, the tests need to wait for it even
after getting the image/video-done.
Capsfilters are created on the constructor and their properties can
be set/get from camerabin2's set/get_property functions. The user with
a broken setup would cause assertions when trying to set/get the
capture caps of this camerabin2.
A proper missing-plugin message will be posted when the user tries to
set camerabin2 to READY state.
There does not seem to be a way to retrieve information
about why failure occured, unfortunately.
When failure occurs, do not post a NULL fingerprint tag.
https://bugzilla.gnome.org/show_bug.cgi?id=656641
