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
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
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.
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
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
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
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
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
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.
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
When extrapolating the offset, we need to use the extrapolate
stride rather then the base stride. This should fix support for format
with more then two planes (I420, Y42B, etc).
When doing frame operation, we need to use the default VideoInfo
and let the frame API read the video meta in order to get the stride
and offset right. Currently we where using the specialized VideoInfo
which reflects what the HW is setup to.
Simplify framerate field if possible, so we don't end up with
e.g. framerate = (fraction) { 30/1 }. Maybe the helper function
should be moved to core, but we can do this later.
This moves away from copying information and store everything inside
the GstVideoInfo structure. The alignement exposed by v4l2 api
is now handled using proper offset.
Return a buffer from an otherpool has unwanted side effects that lead to leaks and
prevents deactivating the pool. Instead, we change the _process() API so it can
replace the internal buffer with the buffer from the downstream pool. This implied
moving from _fill() to _create() method in the src.
Buffer refcounting is a bit hard, because of the duality between CAPTURE and
OUTPUT mode. In the long term, we should consider having two seperate pool
instead of this mess. At least state should be better kept this way.
All enum that has REQBUFS and CREATE_BUFS where missing S, which was
confusing since they are supposed to match with associcated ioctl name. This
also fixes the yet unused CAN_REQUEST flag check.
Because of the buf in videobuf2, dqbuf may leave the DONE flag being,
which would implied that the buffer is queued. As this has been broken
for 4 years, simply guaranty the state flags integrity when doing
qbuf/dqbuf.
See https://patchwork.linuxtv.org/patch/23641/
Improve decide allocation so it properly configure both local and downstream
buffer pools. Also read back the pool config if it was changed to to driver
limitations.
Pre-configuring the pool is error prone, since it may hide a configuration failure and
endup with a pool that is not configured the way it should (e.g. no video meta, wrong
queue size, etc.)
Catch short allocation after saving the format. This is not a catch all, but should catch
most of the miss-behaving drivers when doing S_FMT/G_FMT and avoid potential crash.
This goal of this allocator is mainly to allow tracking the memory.
Currently, when a buffer memory has been modified, the buffer and it's
memory is disposed and lost until the stream is restarted.
Some well known decoder wrongly set num_planes to 0 in their format instead of
one. In this case we would endup with no size when deciding buffer allocation.
In order to correctly set the pool min/max, we need to probe for CREATE_BUFS
ioctl. This can be done as soon as the format has been negotiated using a
count of 0.
Now that we might be copying out buffer (e.g. downstream don't support video
meta bug we need it) we need to move the EOS handling inside the process
method.
As soon a the alpha component can be set, we can expose the RGB32 and BGR32
format as ARGB and BGRA as long we can deterministically set the alpha padding
value.
In certain cases we cannot live without video meta and/or crop meta
being enabled in our internal buffer pool. Ensure this is always the case,
regardless of having support for allocation query.
Upon error, the pools might not have been allocated yet, hence we should not
try and flush them (even though we still want to make sure the processing thread
is fully stopped).
Buffer pool was guessing wrongly the number of planes rather
then reading the value from obj->n_v4l2_planes. This was causing
format YU12 (I420) to fail upon check.
The complex mechanic to try and choose the right thing did not work. Instead,
simply probe the non-contiguous format first and then the contiguous one.
This is in fact very low overhead, as there is a relatively small number of
pixel format supported by each devices.
Certain decoder has been found to not choose a format automatically. Running
v4l2videodec on these would assert. This patch will make it fail cleanly
instead.
If caps are set again, we have a risk od returning from set_format with a
input_state pointing to dead memory. Clearing the pointer after unref fix
this issue.
Uppon certain downstream error, stop() is called without a flush(). This mean that
the streaming thread may still be running even though unlock has been called.
Now calling flush to reset the decoder state if we are processing.
Simplify sub-instanciation by defining an absract type and using subtype
class and instance init callback. This also fixes a bug where the template
pads get initialized too late.
https://bugzilla.gnome.org/show_bug.cgi?id=727925
For format like mpegts, width and height is rarely in the negotiated caps. This
patch fixes failure when setting format, and prevent introducing width, height,
framerate and format to the caps when fixating.
https://bugzilla.gnome.org/show_bug.cgi?id=725860
It seems that GStreamer's mpegts elements (tsdemux, tsparse) require caps
`video/mpegts,systemstream=true`. As far as I can see the significance
of systemstream is to indicate that this is a container format rather than
an elementary stream. As this is the case (and I can't understand how it
could not be the case with mpegts) I add systemstream=true to v4l2src's
caps.
This allows v4l2src to be linked with tsdemux for playback from my
Hauppauge HD-PVR with the pipeline:
v4l2src ! queue ! tsdemux ! video/x-h264 ! decodebin ! xvimagesink
In combination with the next commit this fixes using Hauppauge HD-PVR with
GStreamer 1.0+.
Adds type compatiblity with other OS like BSD. This uses types mapping macro to
avoid conflict with existing defined types. We resuse glib types as these are
already available on supported platforms. This is GCC only because of the
le32 type that uses bitwise attribute.
https://bugzilla.gnome.org/show_bug.cgi?id=726453
With years the amount of ifdef have grown up and we are not even sure if the
old code path compiles. Each time we need to update the v4l2 framework to add
the new feature, we break compilation on older kernel. With exception of two
controls in the video orientation control, this patch get rid of all ifdef by
including the latest version of videodev2.h inside GStreamer.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=723446
V4L2 kernel drivers allow configuration of the hardware settings via a
mechanism called controls. These can be referred to by name such as
"Brightness" and "White Balance Temperature". The user-space command line
client for setting these controls (v4l2-ctl) normalises these names such
that they only contain lower case alphanumeric characters and the
underscore '_'. e.g:
Kernel v4l2-ctl
----------------------------------------------------
Brightness brightness
White Balance Temperature white_balance_temperature
Focus (absolute) focus_absolute
GStreamer seems to want to follow this pattern but failed for controls with
more than one consecutive non-alphanum character. e.g. GStreamer would
produce "focus__absolute_" rather than "focus_absolute".
This commit fixes that issue. Backwards compatibility is preserved by
normalising all control names before comparison.
https://bugzilla.gnome.org/show_bug.cgi?id=725632
For each videoCdevice probe it input/output capabilities
if it match with video decoder requirement register a new element.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
https://bugzilla.gnome.org/show_bug.cgi?id=722128
We correctly indicate the field ordering on interlaced buffers, but fail to
flag them as containing interlaced video, which we need to do here because
we signal interlace-mode=mixed in our caps. This means that downstream
elements (like vaapipostproc from gstreamer-vaapi) don't recognise these
buffers as in need of deinterlacing.
Fix this by setting the interlaced flag on all interlaced buffers.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
https://bugzilla.gnome.org/show_bug.cgi?id=724899
This may not be defined. Since the previous version used
only the other define (V4L2_CAP_VIDEO_OUTPUT_MPLANE), fall
back on this only when not available.
Don't enforce having width, height and framerate in template caps for encoded
formats. These don't always need to be exposed and may break negotiation for
decoder and decoding sink. If needed, these field will be automatically added
when probed caps are known.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
STREAMOFF set all v4l2buffers to DEQUEUE state.
Then for CAPTURE we call QBUF on each buffer.
For OUTPUT the buffers are just push back in the GstBufferPool
base class 's queue.
But the loop actually looks like the same.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
If there is nothing that seems to force a certain framerate on output device, it is
preferable to simply not set that feild. This allow negotiation with tsdemux in a
decoder for example.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
Also add a FIXME in gst_v4l2_object_setup_format
to note that the whole function has to be improved
in order to support ENCODED formats.
It requires to have an encoder device which we do not
have right now.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
This method allow setting up the object from the currently configured format on the
device. This is useful for M2M element where input data decides the format that will
be set on capture side.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
The number of plane, and the stride does not represent a capability change. Same caps
can have different stride from the default GstVideoInfo and the number of planes will
never change for 1 format.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
It makes the gst_v4l2_object_set_format() slightly simplier and will make that
logic reusable. Note that gst_v4l2_object_has_mplane() will always return the
same value for one device. There is no need to check against the caps as this
has already been done by _open.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
We set the dimensions just in case but don't validate them
afterwards. For some codecs the dimensions are *not* in the
bitstream, IIRC VC1 in ASF mode for example.
https://bugzilla.gnome.org/show_bug.cgi?id=720568
so that the buffer informations can be retrieved the same way
in both MPLANE and non-MPLANE mode.
Here "emulating" means "manually fill in the plane".
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=712754
This api is in linux kernel since version 2.6.39,
and present in all version 3.
The commit that adds the API in master branch of the
linux kernel source is:
f8f3914cf9
v4l2 doc: "Some devices require data for each input
or output video frame to be placed in discontiguous
memory buffers"
There are newer structures 'struct v4l2_pix_format_mplane'
and 'struct v4l2_plane'.
So the pixel format is not setup with the same API when using
multi-planar.
Also for gst-v4l2, one of the difference is that in GstV4l2Meta
there are now one mem pointer for each maped plane.
When not using multi-planar, this commit takes care of keeping
the same code path than previously. So that the 2 cases are
in two different blocks triggered from V4L2_TYPE_IS_MULTIPLANAR.
Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=712754
It's unfortunate to have to do this, but with the mix of tabs and space, plus all the random
indentation this header has become very hard to read.
https://bugzilla.gnome.org/show_bug.cgi?id=712754
On some systems (E.G. uClibc and older Glibc versions), O_CLOEXEC is only
defined when _GNU_SOURCE is specified, so do so.
_GNU_SOURCE needs to be defined before any system headers are included,
so move the fcntl.h section up.
https://bugzilla.gnome.org/show_bug.cgi?id=709423
If the pool is stopped while gst_v4l2_buffer_pool_dqbuf() waits for a
buffer then the return value is GST_FLOW_FLUSHING. In this case the buffer
to queue must also be released. Otherwise is will never be deleted or
returned to its pool.
https://bugzilla.gnome.org/show_bug.cgi?id=703764
gst_video_info_from_caps() always extract width, height, interlace mode and
framerate now. It is no longer necessary to do it again for encoded
formats.
https://bugzilla.gnome.org/show_bug.cgi?id=703399
As cameras tend to have a quite specific set of capabilities (specific
framerates for each resolution), getting the peer caps filtered by our
probed caps can cause a big increase in the caps size which slows down
things quire a bit.
As for negotiation v4l2 iterates through the caps of the peer to find the
first intersection with the probed caps, getting the fully expanded
intersection of capabilities is not useful.
Using the same testcase as for bug #702632, adding this patch on top of
the patches suggested there speeds up getting the inital frame from
around ~14-15 seconds to around ~3-4 seconds.
https://bugzilla.gnome.org/show_bug.cgi?id=702638
The pool accesses data from the v4l2object so it must exist at least
as long as the pool. Refcount the element which controls the object
live-time.
https://bugzilla.gnome.org/show_bug.cgi?id=701650
In v2.6.18 control classes where added to the v4l2 API.
Iterating over CIDs starting with V4L2_CID_BASE will only find controls for
the first control class.
By iterating with V4L2_CTRL_FLAG_NEXT_CTRL all controls are found.
This is necessary to make controls from other control classes available in
the extra-controls property.
If V4L2_CTRL_FLAG_NEXT_CTRL is not defined at compile time or not supported
at runtime then the old mechanism for iterating is used.
https://bugzilla.gnome.org/show_bug.cgi?id=701540
Instead of just assuming a aspect ratio of 1/1 use VIDIOC_CROPCAP to ask
the device.
This also add a pixel-aspect-ratio property to overwrite the value from the
driver and a force-aspect-ratio property to ignore it.
https://bugzilla.gnome.org/show_bug.cgi?id=700285
Without this the following sequence fails:
- set_caps()
- object_stop() (does nothing)
- set_format() -> VIDIOC_S_FMT
- set_config() -> VIDIOC_REQBUFS with count = N
- set_caps()
- object_stop()
- pool_finalize()
- set_format() -> VIDIOC_S_FMT => EBUSY
Usually the pool is started after set_config(), in which case object_stop()
will result in a pool_stop and therefore VIDIOC_REQBUFS with count = 0 but
that is not guaranteed.
Also calling VIDIOC_REQBUFS with count = 0 in pool_finalize() if necessary
fixes this problem.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701543
This is a followup patch for #700781, which is not quite correct.
The buffer handling is quite complicated here.
The original code intended to the the following:
- gst_v4l2_buffer_pool_process() calls QBUF and adds the buffer to the
local list.
- The sink calls gst_buffer_unref() which returns the buffer to the pool
but not the 'free list'.
- Some time later DQBUF returns the buffer and
gst_v4l2_buffer_pool_release_buffer() puts in on the 'free list'.
If the buffer must be copied then (parent_class)->acquire_buffer() is
called directly to keep the buffer in the pool.
This has two problems:
1. If gst_v4l2_buffer_pool_release_buffer() is called before the buffer is
returned to the pool, then the buffer is put on the 'free list' twice.
This can happen if a reference to the buffer is kept outside the sink,
of if DQBUF returns the buffer, that was just queued with QBUF.
2. If buffers are copied, then all buffers are in the pool at all times. As
a result gst_v4l2_buffer_pool_stop() and gst_v4l2_buffer_pool_dqbuf()
can access pool->buffers at the same time, which can lead to memory
corruption.
The patch for #700781 fixes those problems, but with the side effect that
there are always buffers outside the pool (because they are queued) and
the pool is never stopped.
This patch fixes this by releasing the reference to the buffer after
handling it (to avoid problem 2.) so it can be returned to the pool.
gst_v4l2_buffer_pool_release_buffer() is only called if the buffer is
already in the pool (to avoid problem 1.).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701375
This makes it possible to set any controls that can be set with
VIDIOC_S_CTRL.
The controls are set when the property is set (if the device is open)
and when the device is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=698837
Without this, a queued buffer may be required, filled and queued before it
is dequeued.
Calling gst_buffer_pool_acquire_buffer() ensures that the buffer is set up
correctly and gst_buffer_unref() calls buffer_release().
https://bugzilla.gnome.org/show_bug.cgi?id=700781
This can happen if other parts of the pipeline are reconfigured.
Stop streaming even for a short amount of time can be quite visible, so it
should be avoided if possible.
https://bugzilla.gnome.org/show_bug.cgi?id=700503
When queuing a buffer for a sink, bytesused must contain the actual
amount of data.
For a source, the driver must overwrite this, so it doesn't matter
what is set here.
https://bugzilla.gnome.org/show_bug.cgi?id=699598
In the past gst_video_info_from_caps() only video/x-raw. Now it also
supports other video/* and image/* formats.
With this patch the format won't be GST_VIDEO_FORMAT_UNKOWN and
gst_v4l2_buffer_pool_set_config() handles strides correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=699570
If max_buffers is 0 then an arbitrary number of buffers (currently 4) is
allocated. If this is not enough v4l2src starts copying buffers.
With this patch VIDIOC_CREATE_BUFS is used to allocate a new buffer. If
this fails v4l2src falls back to copying buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=699447
The existence of a GstVideoFormatInfo does not guarantee, that
the buffer contains video frames, so the format must be checked.
Also, for encoded buffers the length is variable and must be set.
https://bugzilla.gnome.org/show_bug.cgi?id=698949
