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
Improve buffer validation by making sure each memory are the right
one and that each memory is writable. This fixes tearing issues in
case downstream uses gst_buffer_make_writable() or other type
of GstBuffer copy where memory are only reffed.
https://bugzilla.gnome.org/show_bug.cgi?id=739754
Rather than try and guess interlace support as part of checking supported
sizes, look for interlace support specifically in its own function.
As a cleanup, use V4L2_FIELD_ANY when probing sizes, which should result in
the driver doing the right thing.
With my capture setup, this gets me the following sample caps:
For 1080i resolution:
video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, framerate=(fraction){ 25/1, 30/1 }
For 720p resolution:
video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction){ 50/1, 60/1 }
For 576i/p resolution (both possible at the point of query):
video/x-raw, format=(string)YUY2, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string){ progressive, interleaved }, framerate=(fraction){ 25/1, 50/1 }
This, in turn, makes 576i work correctly; with the old code,
the caps would be interlace-mode=progressive for interlaced video.
https://bugzilla.gnome.org/show_bug.cgi?id=726194
On streamon failure, the queued buffer is not released from the
bufferpool class point of view because it is queued to the driver and
the flush logic is not performed since we are not in streaming state.
It causes the v4l2 bufferpool to always return that stop method failed
and to leak v4l2 objects and buffers.
This commit solve this by performing the flush logic in error case, ie
flushing the allocator and restoring queued buffer state to non-queued.
https://bugzilla.gnome.org/show_bug.cgi?id=738102
This will prevent deadlocks, but will also properly flush the pool and allocator
when going to READY state. It should also fix issues reported on mailing list
when seeking is performed.
https://bugzilla.gnome.org/show_bug.cgi?id=738152
When the v4l2 device is an output device, the application shall set the
colorspace. So map GStreamer colorimetry info to V4L2 colorspace and set
on set_format. In case we have no colorimetry information, we try to
guess it according to pixel format and video size.
https://bugzilla.gnome.org/show_bug.cgi?id=737579
Use XQueryPointer to check that the pointer is actually active inside
the capturing region.
This prevents drawing the cursor when the pointer is partially outside
of the captured region but not active inside the region; in particular
this avoids drawing the "window resize" cursor shapes to the captured
image when the mouse pointer crosses a window border.
NOTE that this is not only an optimization, this also happen to fix
a serious problem in multi-screen setups.
Because XFixes gives no information of what screen the pointer is on,
ximagesrc was always drawing the cursor on the captured screen even if
the mouse pointer was on another screen.
For example, when capturing from screen 1 (i.e. display-name=":0.1") the
cursor was drawn in the captured image even when the mouse pointer was
actually on screen 0, which is wrong and visually confusing.
https://bugzilla.gnome.org/show_bug.cgi?id=690646
When the cursor is partially or totally out of the capturing region on
the top side or on the left side, it gets drawn fully inside of the
region with its coordinates rounded up to the left or to the top border.
This is immediately noticeable when using the xid property to capture
a specific window.
To fix the issue, allow negative cx and cx coordinates when checking the
boundaries before drawing the cursor.
NOTE that the boundaries checking calculations still allows the cursor
to be drawn when it is only partially outside of the capturing region,
but this makes sense and gives a more pleasing visual behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=690646
XFixes provides the cursor coordinates relative to the root window, this
is not taken into account when using the xid property to capture
a specific window, the result is that the cursor gets drawn at the wrong
position.
In order to fix this consider the window location when calculating the
cursor position in the destination image.
https://bugzilla.gnome.org/show_bug.cgi?id=690646
This will prevent the converter to be picked automatically in case
someone implement dynamic converter selection support. I'd like this
to be ranked only for known device, as it's hard to be sure a device is
a converter suited for general purpose. Re-negotiation is also needed
before we can rank it.
https://bugzilla.gnome.org/show_bug.cgi?id=733607
Even though the UVC driver do a great deal of effort to prevent bad
timestamp to be sent to userspace, there still exist UVC hardware that
are so buggy that the timestamp endup nearly random. This code detect
and ignore timestamp from these drivers, making these camera usable.
This has been tested on both invalid and valid cameras, making sure it
does not trigger for valid cameras.
https://bugzilla.gnome.org/show_bug.cgi?id=732910
There is still around 18 drivers not yet ported to videobuf2. These driver
don't support freeing buffetrs through REQBUFS(0) hence for these the
memory type probing fails. In order to gain back our previous behaviour in
presence of these, we implement a workaround that assuming MMAP is
supported. Note that an allocator is only created for device with
STREAMING support in the device capabilities. In such case one of MMAP,
USERPTR and DMABUF is required. Though DMABUF came afterward, so is
not an option and in practice none of these drivers will only do USERPTR.
https://bugzilla.gnome.org/show_bug.cgi?id=735660
Also-by: Hans de Goede <hdegoede@redhat.com>
Since we can get the minimum number of buffers needed by an output
device to work, use it to set min_latency which will determine how many
buffers are queued.
https://bugzilla.gnome.org/show_bug.cgi?id=736072
Most V4L2 ioctls like try_fmt will adjust input fields to match what the
hardware can do rather then returning -EINVAL. As is docmented here:
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html
EINVAL is only returned if the buffer type field is invalid or not supported.
So upon requesting V4L2_FIELD_NONE devices which can only do interlaced
mode will change the field value to e.g. V4L2_FIELD_BOTTOM as only returning
half the lines is the closest they can do to progressive modes.
In essence this means that we've failed to get a (usable) progessive mode
and should fall back to interlaced mode.
This commit adds a check for having gotten a usable field value after the first
try_fmt, to force fallback to interlaced mode even if the try_fmt succeeded,
thereby fixing get_nearest_size failing on these devices.
https://bugzilla.gnome.org/show_bug.cgi?id=735660
They may have been modified by the ioctl even if it failed. This also makes
the S_FMT fallback path try progressive first, making it consistent with the
preferred TRY_FMT path.
https://bugzilla.gnome.org/show_bug.cgi?id=735660
If the minimum required buffer exceed V4L2 capacity, don't share down
pool. This allow support very high latency, like with x264enc default
encoding settings.
https://bugzilla.gnome.org/show_bug.cgi?id=732288
Some v4l2 devices could require a minimum buffers different from default
values. Rather than blindly propose a pool with min-buffers set to the
default value, it ask the device using control ioctl.
https://bugzilla.gnome.org/show_bug.cgi?id=733750
These checks are no longer required with recent change to the bufferpool. This
should allow changing the configuartion, hence the way forward renegotiation
support.
https://bugzilla.gnome.org/show_bug.cgi?id=728268
We cannot allocate new buffer in acquire, otherwise the base class
is not aware and get confused. Instead, copy in _process(). This leads
to crash on finalize.
Fixes regression, see https://bugzilla.gnome.org/show_bug.cgi?id=732912
Parenting V4l2Memory to DmabufMemory was in conflict with recent
optimization in DmabufMemory to avoid dup(), and didn't work with
memory sharing. Instead, use a qdata and it's destroy notify.
https://bugzilla.gnome.org/show_bug.cgi?id=730441
Before we would hit an assertion "'gst_buffer_pool_is_active (bpool)' failed"
if the internal pool was not used to push buffer downstrea, hence not
given to the baseclass.
https://bugzilla.gnome.org/show_bug.cgi?id=732912
If special stride is needed and downstream don't support VideoMeta,
pool might be NULL in order to let the baseclass create a generic
pool. This would lead to assertion with on Exynos with:
gst-launch-1.0 -v filesrc location=mov ! qtdemux ! h264parse ! \
v4l2video8dec ! fakesink
https://bugzilla.gnome.org/show_bug.cgi?id=732707
In kernel before 3.17, polling during queue underrun would unblock right
away and trigger POLLERR. As we are not handling POLLERR, we would endup
blocking in DQBUF call, which won't be unblocked correctly when going
to NULL state. A deadlock at start caused by locking error in libv4l2 was
also seen before this patch. Instead, we wait until the queue is no longer
empty before polling.
https://bugzilla.gnome.org/show_bug.cgi?id=731015
The code enumerating STEPWISE framesizes would start from
(min_w, min_h) and then add (step_w, step_h) to get the
next framesize. However, it should really allow any width
from min_w to max_w with step_w and same for heights.
Secondly, we would add and probe each individual stepped
frame size to the caps as separate structure, which would
lead to hundreds if not thousands of structs ending up in
the probed caps. Use integer ranges with steps instead.
This was particularly noticable with the Raspberry Pi Cam.
https://bugzilla.gnome.org/show_bug.cgi?id=724521https://bugzilla.gnome.org/show_bug.cgi?id=732458https://bugzilla.gnome.org/show_bug.cgi?id=726521
This workaround from 2011 was causing 25 S_FMT ioctls to be sent
to my UVC webcam from under gst_v4l2_object_get_caps as it probes
all the formats. In total, this adds up to about 5 seconds of
execution time, or a 10 second delay while starting up cheese.
These ioctls come from a workaround from 2011 where TRY_FMT might
make changes to hardware settings, so S_FMT was used to restore
the original config:
https://bugzilla.gnome.org/show_bug.cgi?id=649067
The driver bug is now assumed fixed. Remove the workaround to fix the
long startup delay.
https://bugzilla.gnome.org/show_bug.cgi?id=732326
"have-ns-view" and the "embed" property was kept in 0.10 for
backwards compatibility but it's no longer used in favor of
the GstVideoOverlay interface
https://bugzilla.gnome.org/show_bug.cgi?id=703753
Probe supported formats in order of desirability rather than in
what order they may happen to be in the formats bitmask. Fixes
accidentally exposure of 8-bit formats in caps before 16-bit formats
(in case where U16 was not supported S8 might be listed before S16).
https://bugzilla.gnome.org/show_bug.cgi?id=706884
This is required as during preroll we pass the first buffer twice, hence already
queued. It is also useful, to allow filters replaying a previous rendered buffers.
This will require 1 more buffer in sink if last-sample is enabled, since the last
sample will not be the same as the currently queued buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=722303
For output device, we where queuing all the buffers, and then we would
dequeue one. This means we only have 1 buffer for the pipeline, no matter
the size of the queue. Instead, start dequeued when min_latency is reached.
Eventually, this the min_latency should also be affected by control
MIN_BUFFERS_FOR_OUTPUT (use by encoders).
Calculation of num_buffers (the max latency in buffers) was
up-side-down. If we can allcoate, then our maximum latency match
pool maximum number of buffers. Also renamed it to max latency. Finally
introduced a min_latency for clarity.
Fix the choice of min/max, don't override the min/max with own pool selected
size, correct other_pool is_active check, start from other_pool config when
configuring the other pool and finally validate the configuration.
The decodeing thread returning flushing isn't an error, we should simply
try starting the task again. If it's actually flushing, it will stop again by itself.
From time to time, when the image_pool list has more then 1 element
and I suppose at start, all but 1 pooled ximage are leaked. This is
due to broken algorithm in gst_ximagesink_src_ximage_get(). There was
also a risk of use after free for the case where the ximage size has
changed.
https://bugzilla.gnome.org/show_bug.cgi?id=728502
gstv4l2bufferpool.c:608:18: error: implicit conversion from enumeration type
'enum _GstV4l2BufferPoolAcquireFlags' to different enumeration type
'GstBufferPoolAcquireFlags' [-Werror,-Wenum-conversion]
params.flags = GST_V4L2_POOL_ACQUIRE_FLAG_RESURECT;
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We need to handle the case where a flush occure while the streaming
thread is being brought up. In this case, the flushing state of the poll
object is cleared. To solve this, we simply set the capture poll to flushing
again, this way we know the thread will exit. The decoder streamlock
is used to synchronize with handle frame.
M2M devices were sharing the same properties as src and sink. Most of
these made no sense. This patch reduces the number of propeties and
makes io-mode clearer by having capture-io-mode and output-io-mode. This
also accidently fixed a bug in gstv4l2transform io-mode code, where the
capture io-mode could not be set.
https://bugzilla.gnome.org/show_bug.cgi?id=729591
If the driver need more buffers than requested by the config,
update the pool min/max values. The minimum value for the pool
could be provided either by the driver or by the pool. This is
best effort for drivers that don't support
CID V4L2_CID_MIN_BUFFERS_FOR_CAPTURE.
https://bugzilla.gnome.org/show_bug.cgi?id=730200
This allow calling start streaming later for capture device. Currently it breaks
in dmabuf-import because downstream is holding a buffer that will only be
released after stream-start.
https://bugzilla.gnome.org/show_bug.cgi?id=730207
