UVC devices are never interlaced, and doing VIDIOC_TRY_FMT on them
causes expensive and slow USB IO, so don't probe them for interlaced.
This shaves 2 seconds of the startup time of cheese with a Logitech
Webcam Pro 9000.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=677722
These should all be int instead of long, to avoid bugs
when passing these as varargs with g_object_set(), and
there was no reason to use long in the first place here.
Fixes FIXME.
Post the notify outside of the pa_lock to avoid a deadlock caused by basesrc
calling get_time with the object lock.
Reset the clock on connect.
Post clock-lost and clock-provide messages.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=673977
Conflicts:
ext/pulse/pulsesrc.c
They should take the filter caps into account and always return
the template caps appended to the actual caps. Otherwise the
parsers stop to accept unparsed streams where upstream does not
know about channels, rate, etc.
Fixes bug #677401.
Block gst_osx_video_sink_run_cocoa_loop until the loop thread has started and
finished initializing NSApp. Fixes occasional warnings/crashes due to two
threads going inside NSApp before finishLaunching had completed.
Leave it to the application to decide on the header. No header at all
is better than having the wrong header as DLNA mandates that a missing
header has to be tolerated while a wrong header is an error.
https://bugzilla.gnome.org/show_bug.cgi?id=676020
From RFC 2250
2. Encapsulation of MPEG System and Transport Streams
...
For MPEG2 Transport Streams the RTP payload will contain an integral
number of MPEG transport packets. To avoid end system
inefficiencies, data from multiple small MTS packets (normally fixed
in size at 188 bytes) are aggregated into a single RTP packet. The
number of transport packets contained is computed by dividing RTP
payload length by the length of an MTS packet (188).
....
Since it needs to contain "an integral number of MPEG transport packets", a
simple fix is to check that's the case, and strip off any leftover data.
Fixes#676799
Conflicts:
gst/rtp/gstrtpmp2tdepay.c
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.
