If GetStatus() fails, the status itself won't be very meaningful but we also
have to look at its return value. This fixes blocking pipelines when removing
sound devices or during other errors, where we wouldn't notice the error and
then wait forever.
https://bugzilla.gnome.org/show_bug.cgi?id=734098
If something in /dev/video* get added, removed or replaced, we need to
probe the devices again in order to ensure the dynamic devices are up to
date.
https://bugzilla.gnome.org/show_bug.cgi?id=758085
There was some miss-match in the implementation. This makes it
concistent, though functionally it worked, except the video decoder
output-io-mode getter.
These days the xserver seems to give us the same damage regions
over and over for entire windows, and we retrieve them multiple
times, which gives time for more damage to appear. Instead, just
quickly gather all damaged areas into a region list and copy
out once.
For 1ch or 2ch devices, we just need to set the caps to allow both
options since CoreAudio will up/downmix appropriately.
Also fixes the condition for the 2ch case to be exact, rather than at
least 2 channels since the downmix will not take place in the >stereo
case.
We need to initialize the AudioUnit early to be able to probe the
underlying device, but according to the AudioUnitInitialize() and
AudioUnitUninitialize() documentation, format changes should be done
while the AudioUnit is uninitialized. So we explicitly uninitialize the
AudioUnit during a format change and reinitialize it when we're done.
_audio_unit_property_listener is called either from a Core Audio thread
or as a result of a Core Audio API (e.g. AudioUnitInitialize)
from our own thread. In the latter case, osxbuf can be already locked
(GStreamer's mutex is not recursive).
We introduce the flag cached_caps_valid and use it instead of nullifying
cached_caps when we cannot lock on osxbuf.
https://bugzilla.gnome.org/show_bug.cgi?id=743758
- Probing caps is unified between source and sink
- Hardware stream format is now reported as preferred capabilities
(dynamically updated when hardware configuration changes)
- Get hardware channel layout from Remote IO just like from HAL
- More comprehensive mapping between AudioChannelLabel and
GstAudioChannelPosition
- Support for unpositioned channel layouts
- Announce stereo-mono upmixing/downmixing in caps
https://bugzilla.gnome.org/show_bug.cgi?id=743758
ximage metadata can't be transformed or copied, but provide an empty
transformation function instead of NULL to allow unconditional calling
of metas' transform functions.
https://bugzilla.gnome.org/show_bug.cgi?id=751778
AudioUnitGetProperty would fail with kParamErr (-50) every time,
simply because size wasn't initialized.
Now it returns zero latency, but at least it doesn't fail.
https://bugzilla.gnome.org/show_bug.cgi?id=750868
This fixes wrong mapping for sRGB as in GStreamer sRGB correctly
apply to RGB formats, while in V4L2 it's an alias for sYCC. Also
add support for the new quantization (range), ycbcr_encoding (matrix)
and xfer_func (transfer) enumeration.
This is the latest from media tree. This should enable more development
of the v4l2 elements. This includes new flags requires to fix draining
path in decoder, colorimetry and much more.
The v4l2 device restarts the sequence counter in case of streamoff/streamon,
the GST offset values are supposed to increment strictly monotonic, so
adjust the sequence counter/offset values in case of caps
renegotiation.
https://bugzilla.gnome.org/show_bug.cgi?id=745441
In case of v4l2 driver filled offset/sequence values add frame
loss detection (and write a warning message).
Move offset meta data setting and frame loss checking after the
timestamp adjustment code to get proper timestamps for the
warning message.
https://bugzilla.gnome.org/show_bug.cgi?id=745441
If propose_allocation() had not been called yet, it was possible that the driver was not asked at all.
In buffer pool: Consider minimum number of buffers requested by driver when setting config.
https://bugzilla.gnome.org/show_bug.cgi?id=746834
cocoawindow.m:339:5: error: 'NSOpenGLPFAWindow'
is deprecated: first deprecated in OS X 10.9
cocoawindow.m:576:7: error: 'NSOpenGLPFAFullScreen'
is deprecated: first deprecated in OS X 10.6
cocoawindow.m:605:24: error: 'setFullScreen'
is deprecated: first deprecated in OS X 10.7
Allow renegotiation to happen when buffers have returned after an allocation
query. As the allocation query is serialized, all buffers from the pool
should have returned and we can stop it to create a new one for the
new format
https://bugzilla.gnome.org/show_bug.cgi?id=682770
For output device, we should not update the buffer with flags and
timestamp when we dequeue. The information in the v4l2_buffer is not
meaningful and it breaks the case where the buffer is rendered at
multiple places.
https://bugzilla.gnome.org/show_bug.cgi?id=745438
The ringbuffer does allow renegotiation, so we do not have to report
fixed caps once it is acquired (based on a similar patch for the sink
side by Ilya Konstantinov <ilya.konstantinov@gmail.com>).
Once osxaudiosink's device is open, it fixates on the initial caps and
refuses to accept new caps. This is erroneous since the Audio Unit is
can accept a new ASBD, and GstAudioRingBuffer supports reconfiguration
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=743925
Ensure gst_v4l2_buffer_pool_release_buffer() releases the associated
GstV4l2MemoryGroup. In particular, this allows for closing the DMABUF
handles prior to instantiating new ones.
https://bugzilla.gnome.org/show_bug.cgi?id=745443
As it's very common, handle driver not setting field in buffers
by using the field value from the format. This workaround a long time
bug in UVC driver. For even buggier driver, we simply assume
progressive as before. We also only warn once, to avoid spamming.
S_CROP ioctl is write-only and the device can adjust crop rectangle so
we query back the crop configuration after each S_CROP to know what has
been done.
https://bugzilla.gnome.org/show_bug.cgi?id=736133
In the V4L2 single-planar API, when format is semi-planar/planar,
drivers expect the planes to be contiguous in memory.
So this commit change the way we handle semi-planar/planar format
(n_planes > 1) when we use the single-planar API (group->n_mem == 1).
To check that planes are contiguous and have expected size, ie: no
padding. We test the fact that plane 'i' start address + plane 'i'
expected size equals to plane 'i + 1' start address. If not, we return
in error.
Math are done in bufferpool rather than in allocator because the
former is aware of video info.
https://bugzilla.gnome.org/show_bug.cgi?id=738013
Offset are relative to the buffer and there is no guarantee substracting
them will give us the plane size. So we let bufferpool make the math as
it is more aware of video info than allocator and pass a size array to
allocator import function.
Pointed out by Nicolas Dufresne <nicolas.dufresne@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=738013
Fixes stuttering audio when iOS AU is resampling. To make AU resample,
one has to request a rate that differs from AVAudioSession's
sampleRate. The resampling itself is not the culprit, but rather our
API misuse.
AudioUnitRender modifies the mDataByteSize members with the
actual read bytes count. Therefore, they must be reinitialized
before each AudioUnitRender. (The buffers themselves can be
preallocated.)
The "stutter" was caused by one AudioUnitRender making the buffer
too small for other AudioUnitRender invocations, making them fail
with -50 (paramErr). By way of luck, when AU didn't resample, all
AudioUnitRender invocations read the same number of bytes.
(This patch addresses some non-interleaved audio concerns, but
at this moment the elements do not support non-interleaved audio
and non-interleaved is untested.)
https://bugzilla.gnome.org/show_bug.cgi?id=744922
When there is no allocation parameters in the query, enable copy
threshold. When this threshold is reached, the buffer pool will start
copying when the pool reaches a critical level. If the driver supports
CREATE_BUFS, this will be used instead.
When we hit emulated formats, we disable CREATE_BUFS since libv4l2
cope very badly with it. Also clear the allocator flags so we will
never try to allocate more buffers. This fixes failure when the copy
threshold is reached as we where calling CREATE_BUFS, which lead to
libv4l2 instability.
In the fraction 1 / 2. 1 is the numerator and 2 is the denominator.
The arguments of fraction gst_value_set_fractions() are value,
numerator and denominator.
Also, gst_value_set_fraction() fails if denominator is 0 for obvious
reasons.
When importing buffers from a downstream pool, we need to deactivate
that pool to ensure it will be usable again later. Relying on the
refcount to reach zero does not work, since elements like xvimagesink
keeps a reference on their proposed pool.
When memory (that has been shared using gst_memory_share()) are freed,
the memory (or the DMABUF FD) should not bee freed. These memories have
a parent. This also removes the extra _v4l2mem_free function and avoid
calling close twice on the DMABUF FD.
https://bugzilla.gnome.org/show_bug.cgi?id=744573
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
