Replace the sink_query with new getcaps() virtual and use the proxy
helper with the probed caps. This allow upstream element taking decision
base on what is supported downstream.
The hack causes deadlocks and other interesting problems and it really
can only be fixed properly inside GLib. We will include a patch for
GLib in our builds for now that handles this, and hopefully at some
point GLib will also merge a proper solution.
A proper solution would first require to refactor the polling in
GMainContext to only provide a single fd, e.g. via epoll/kqueue
or a thread like the one added by our patch. Then this single
fd could be retrieved from the GMainContext and directly integrated
into a NSRunLoop.
https://bugzilla.gnome.org/show_bug.cgi?id=741450https://bugzilla.gnome.org/show_bug.cgi?id=704374
v4l2loopback driver has a this nasty bug that if the queue is larger
then 2 buffers, it returns random index on dqbuf. So far we assumed
that the index was always right, which would lead to memory being
unref twice, and eventually crash.
As the buffer array is fixed size and small, it's safer to simply
use this static size to cleanup the buffers. This is also more
consistent with the rest. The associated method is no longer
required and can be dropped.
This partly revert to the old 1.2 behavior. Instead of keeping a
reference to the output buffer queued, we simply release them but
don't forward it to GstBufferPool. This way, the buffer pool don't
need to be flushed to be stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=742074
Failing streamoff prevents allocator from being disposed hence
lead to device FD leak. There is no known cases where streamoff
may fails for which we'd still be streaming. streamoff is known
to fail when a device is being unplugged (in which case errno
19/ENODEV is set).
https://bugzilla.gnome.org/show_bug.cgi?id=732734
After creating the ringbuffer we have to set the device on the ringbuffer as
it defaults to kAudioDeviceUnknown. At this point it can't have changed to
anything else yet and we don't have to notify about changes to the sink/src
"device" property. It's also not a good idea because GstAudioBaseSrc has the
object lock taken while the ringbuffer is created, which might cause a
deadlock if something calls back into the element from "notify::device".
Once the base class is done with the NULL_TO_READY state change, it has opened
the device via the ringbuffer and this might have chosen a different device.
Especially if we initially used kAudioDeviceUnknown. Also notify about this
property change as initially intended by this code.
It looks like libv4l2 support for CREATE_BUF is incomplete. That
combine with existing bugs may lead to crash in GStreamer. These
check will make it robust by:
- Checking create buf index isn't an already in used index
- Checking that the index out of QUERYBUF matches the requested
index
Right now we try to be clever by detecting if device format have
changed or not, and skip setting format in this case. This is valid
behaviour with V4L2, but it's also very error prone. The rational
for not setting these all the time is for speed, though I can't
measure any noticeable gain on any HW I own. Also, until recently,
we where doing get/set on the format for each format we where
probing, making it near to impossible that the format would match.
This also fixes bug where we where skipping frame-rate setting if
format didn't change.
https://bugzilla.gnome.org/show_bug.cgi?id=740636
It's unlikely that setting a channel layout will do much for AC3/DTS
streams. If we find at some point that it does make sense, we can
perform the structure copying unconditionally (i.e., the current code is
wrong, since AC3/DTS will get two structures now - one with the channel
layout, one without).
https://bugzilla.gnome.org/show_bug.cgi?id=740987
Now that device selection has no sink/source-specific bits, we can have
generic device selection for this path. We do need to now track state
changes so we can look up the final device_id once the device is open,
though.
https://bugzilla.gnome.org/show_bug.cgi?id=740987
This is conceptually the right thing to do, and allows us to correctly
catch errors in device selection as well, which we could not do while
creating the ringbuffer.
https://bugzilla.gnome.org/show_bug.cgi?id=740987
If v4l2_buffer.field is V4L2_FIELD_INTERLACED, we set corresponding
GstVideoBuffer flags depending on the video standard.
According to V4L2 specification, M/NTSC transmits the bottom field
first, all other standards the top field first.
https://bugzilla.gnome.org/show_bug.cgi?id=737603
When libv4l2 emulates RW mode on top of MMAP devices, the queues are
only initialized on first read. The problem is that poll() will fail
if called before the queues are initialized and streaming. Workaround
this by doing a zero size read when pool is started in that IO mode.
https://bugzilla.gnome.org/show_bug.cgi?id=740633
This patch fixes CREATE_BUFS support for capture devices. Initially we
would only try and allocate more buffers when the copy threshold
is reached. When the threshold was not set (needed) it would never
happen. Another problem is that on capture side, acquire returns
filled buffer, hence need to pool. We need to set a special flag to
force allocation to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=741134
This allow skipping buffer flagged with ERROR that has no payload.
This is typical behaviour when a recovererable error occured during
capture in the driver, but that no valid data was ever written into that
buffer. This patch also translate V4L2_BUF_FLAG_ERROR into
GST_BUFFER_FLAG_CORRUPTED. Hence decoding error produce
by decoder due to missing frames will now be correctly marked. Finally,
this fixes a buffer leak when EOS is reached.
https://bugzilla.gnome.org/show_bug.cgi?id=740040
If the v4l2 queue support dmabuf select this buffer pool mode
and update the query with allocator.
This patch only concern exporting dmabuf and not importing dmabuf
fd from downstream element.
https://bugzilla.gnome.org/show_bug.cgi?id=699382
