The gst_v4l2_object_acquire_format() function is used by v4l2videodec to obtain
the currently set capture format. Since G_FMT returns the coded size, the
visible size needs to be obtained from the compose rectangle in order to
negotiate it with downstream elements. The G_CROP call hasn't worked on mem2mem
capture queues for a long time. Instead use the G_SELECTION call to obtain the
compose rectangle and only fall back to G_CROP for ancient kernels.
https://bugzilla.gnome.org/show_bug.cgi?id=766381
On modern kernels, the G/S_FMT ioctls will always fail using
V4L2_BUF_TYPE_VIDEO_OVERLAY with VFL_DIR_TX (e.g. real overlay out drivers)
since this is not the intented use (rather rx, according to v4l2 API doc).
Probably this is why the Video Output Overlay interface was created, so if
the driver advertises it we might as well use.
For old kernels (pre 2012) the old way might still work so keeping this for
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=761165
Support for the updated V4L2_PIX_FMT_XRGB555 was added in commit
2538fee2fd however, when setting the format
for use in v4l2 ioctls, the old deprecated format is still used. Convert
this to the new accepted format type, as the preferred format.
https://bugzilla.gnome.org/show_bug.cgi?id=767300
v4l2src can cause an "infinite message loop" when a base control exposed as a
property is not provided by the device. In these cases, if in the warning message
handling for the bus, the GST_DEBUG_BIN_TO_DOT_FILE* category of functions are used,
the src lookup causes a new warning to be posted on the bus, causing a loop.
This patch changes the warning for these controls so they are not posted on the bus.
https://bugzilla.gnome.org/show_bug.cgi?id=758703
A device can support more than one colorspace for a given image
dimension and pixel format. So we have to probe all the supported
colorspace and not only rely on the default one. Otherwise we could end
up with negotiation failure if the caps colorimetry field don't match
the v4l2 device default one even if the v4l2 could support such
colorimetry.
This patch enable probing if colorspace for both capture and output
device. It really makes sense for output device since the colorspace
shall be set by the application and a little less for capture device
which, at the moment, shall provide the colorspace; ie: the v4l2
specification seems to not take into account the fact that a capture
device could do colorspace conversion.
As a side effet, probing takes some times and so sligthly delay v4l2
initialization. Note that this patch only probe colorspace and not all
colorspace, matrix, transfer and range combination to avoid taking too
much time, especially with low-speed devices as full probing do 1782
ioctl.
https://bugzilla.gnome.org/show_bug.cgi?id=755937
gst_v4l2_object_get_caps_info() always return V4L2_PIX_FMT_SBGGR8
for all bayer formats. This is obviously broken if the device use
another ordering. Fix this by properly reading the format parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=763318
Replicate V4L2_MAP_QUANTIZATION_DEFAULT macro behavior.
At #v4l it was described that documentation might be wrong and that
we should trust this macro instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762529
Didn't know which one to choose between queuing and queueing, so I picked
the one with the biggest amount of vowels in a row ;-P (both are
acceptable apparently)
This time, check if it's an RGB format and sets the transformation
matrix to identity. The rest of the colorimetry information is
meaningfull and shall be kept.
https://bugzilla.gnome.org/show_bug.cgi?id=759624
Use the new primaries and transfer function for Adobe RGB.
Explicitly list the colorimetry instead of using the default GStreamer
ones. The defaults for BT2020, for example, do not match.
Explicitly set the matrix of SRGB to RGB.
Add properties to the device with exactly the same keys and sematics
as what pulseaudio uses as property keys.
Also handle the case when a device is probed manually and not through gudev.
https://bugzilla.gnome.org//show_bug.cgi?id=759780
This change add all the new RGB based format. Those format removes the
ambiguity with the ALPHA channel. Some other missing multiplanar format
has been added with some additional cleanup.
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
