First step of a larger cleanup, all function from v4l2_calls are in fact
methods on GstV4l2Object. This split makes the code really confusing.
This also remove no longer unused macros.
Before that, each m2m node would be wrapped as a single, multi-format
decoder element. As a unique name was needed, we where using the device
name, which changes between re-boots. This led to unpredictable element
names. In this patch, we generate an element per codec, using
v4l2<codec>dec name. If there is multiple decoder for the same format,
the following elements will be named v4l2<node><codec>dec.
https://bugzilla.gnome.org/show_bug.cgi?id=784908
When resurrecting a buffer, the subsequent free call can result
in the group-released handler being called again, which causes
a recursive loop. This patch blocks the signal handler during
the time that it executes, ensuring that the loop will not occur.
https://bugzilla.gnome.org/show_bug.cgi?id=759292
Increasing this number fix a buffer starvation problem I'm hitting
with a "v4l2src ! kmssink" pipeline.
kmssink requests 2 buffer as it keeps a reference on the last rendered
one. So we were allocating 3 buffers for the pipeline.
Once the first 2 buffers have been pushed we ended up with:
- one buffer queued in v4l2
- one being pushed
- one kept as last rendered
If this 3rd buffer is released after that v4l2 used the first one to
capture we end up with a buffer starvation problem as no buffer is currently
queued in v4l2 for capture.
Fixing this by adding one extra buffer to the pipeline so when one
buffer is being pushed downstream the other can already be queued to
capture the next frame.
We were already adding 3 buffers if downstream didn't reply to the
allocation query. I reduced this number to 2 to compensate the extra
buffer which is now always added.
https://bugzilla.gnome.org/show_bug.cgi?id=783049
This patch fixes a memory leak that is caused if the dmabuf file
descriptor dup fails. Previously, _cleanup_failed_alloc() would
not unref the memory because mems_allocated had not yet been
incremented.
https://bugzilla.gnome.org/show_bug.cgi?id=784302
When upstream does no use the v4l2videoenc pool, we need to activate
that internal pool. Though, we relied the driver to provide a minimum
required buffer, which Qualcomm Venus driver don't currently provide.
https://bugzilla.gnome.org/show_bug.cgi?id=783361
This implements H264 encoding support using generic V4L2 interface. It is
reported to work with Samsung MFC driver, IXM.6 CODA driver and
Qualcomm mainline Venus driver. Other platform should be supported as
none of this work is platform specific.
The implementation consist of a GstV4l2VideoEnc base class, which
implements the core streaming functionality. This base class is implemented
by GstV4l2H264Enc class that implements the caps negotiation specific to
H264 profiles and level. This implementation supports hardware with multiple
H264 encoder. Though, to make it simplier to use, the first discovered H264
encoder will be named v4l2h264enc. Other encoder found during discovery will
have a unique name like v4l2video0h264enc.
This work is the combined work of multiple developpers in the last 3
years. Thanks to all of the contributors:
Ayaka <ayaka@soulik.info>
Frédéric Sureau <frederic.sureau@vodalys.com>
Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
Nicolas Dufresne <nicolas.dufresne@collabora.com>
Pablo Anton <pablo.anton@vodalys-labs.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728438
This is needed for V4L2_OUTPUT interface, and is harmless of
V4L2_CAPTURE interfaces. This will fix timestamp in cases like:
v4l2src io-mode=dmabuf ! v4l2videoNenc output-io-mode=dmabuf-import ! ...
Same apply for userptr.
https://bugzilla.gnome.org/show_bug.cgi?id=781119
Running `gst-validate-launcher -t validate.file.playback.change_state_intensive.vorbis_vp8_1_webm`
on odroid XU4 (s5p-mfc v4l2 driver) often leads to:
ERROR:../subprojects/gst-plugins-good/sys/v4l2/gstv4l2videodec.c:215:gst_v4l2_video_dec_stop: assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
This happens when the following race happens:
- T0: Main thread
- T1: Upstream streaming thread
- T2. v4l2dec processing thread)
[The decoder is in PAUSED state]
T0. The validate scenario runs `Executing (36/40) set-state: state=null repeat=40`
T1- The decoder handles a frame
T2- A decoded frame is push downstream
T2- Downstream returns FLUSHING as it is already flushing changing state
T2- The decoder stops its processing thread and sets `->processing = FALSE`
T1- The decoder handles another frame
T1- `->process` is FALSE so the decoder restarts its streaming thread
T0- In v4l2dec-> stop the processing thread is stopped
NOTE: At this point the processing thread loop never started.
T0- assertion failed: (g_atomic_int_get (&self->processing) == FALSE)
Here I am removing the whole ->processing logic to base it all on the
GstTask state to avoid duplicating the knowledge.
https://bugzilla.gnome.org/show_bug.cgi?id=778830
Without a specified framerate from the sink, the decoder frame interval
should be set using the framerate of the encoded video stream.
Therefore, the v4l2object should be able to change the framerate on the
output if the V4L2 device accepts it.
This is also necessary for mem2mem encoders so that their bitrate
calculation code may work correctly and they may report the correct
frame duration on the capture queue.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
If the duration of the v4l2object is GST_CLOCK_TIME_NONE, because the
sink did not specify a framerate in the caps and the driver accepts the
framerate, the decoder element uses GST_CLOCK_TIME_NONE to calculate and
set the element latency.
While this is a bug of the capture driver, the decoder element should
not use the invalid duration to calculate a latency, but print a warning
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=779466
The correct behaviour of anything stuck in the ->render() function
between ->unlock() and ->unlock_stop() is to call
gst_base_sink_wait_preroll() and only return an error if this returns an
error, otherwise, it must continue where it left off!
https://bugzilla.gnome.org/show_bug.cgi?id=774945
Update the image size according the amount of data we are going to
read/write. This workaround bugs in driver where the sizeimage provided
by TRY/S_FMT represent the buffer length (maximum size) rather then the expected
bytesused (buffer size).
https://bugzilla.gnome.org/show_bug.cgi?id=775564
Set MAY_BE_LEAKED flag on static pads returned by gst_v4l2_object_get_*_caps()
functions. Made functions thread safe by using g_once_init[enter|leave]
funtions.
https://bugzilla.gnome.org/show_bug.cgi?id=778453
In gst_v4l2_allocator_qbuf(), the memory is referenced after the
buffer is queued. Once queued (VIDIOC_QBUF), the buffer might be handled
by the V4L2 driver (e.g. decoded) and dequeued (gst_v4l2_allocator_dqbuf),
through a different thread, before the memory is referenced (gst_memory_ref).
In this case, in gst_v4l2_allocator_dqbuf(), the memory is unreferenced
(gst_memory_unref) before having been referenced: the memory refcount
reaches 0, and the memory is freed.
So, to avoid this crossing case, in gst_v4l2_allocator_qbuf(), the
memory shall be referenced before the buffer is queued.
https://bugzilla.gnome.org/show_bug.cgi?id=777399
Unlike former definitions of LOG_CAPS, the current implementation simply
expands to GST_DEBUG_OBJECT. The LOG_CAPS macro is rarely used and most
uses duplicate already existing GST_DEBUG_OBJECT lines. Therefore, the
caps are often printed twice which unnecessarily clutters the debug log.
Replace LOG_CAPS calls with GST_DEBUG_OBJECT, remove LOG_CAPS calls, and
delete the definition of LOG_CAPS.
https://bugzilla.gnome.org/show_bug.cgi?id=776899
The buffer memory type provided to the VIDIOC_CREATE_BUFS ioctl shall
be set with the value ("memory") given as input parameter of the
gst_v4l2_allocator_probe() function.
https://bugzilla.gnome.org/show_bug.cgi?id=777327
After commit 1ea9735a I see these error while using the webcam
integrated in my laptop:
GStreamer-CRITICAL **: gst_value_list_get_size: assertion 'GST_VALUE_HOLDS_LIST (value)' failed
The issue is gst_v4l2src_value_simplify() was doing its job of
generating a single value, rather than the original list. That why,
when getting the list size, a critical warning was raised.
This patch takes advantage of the compiler optimizations to verify
first if the list was simplified, thus use it directly, otherwise,
if it is a list, verify its size.
https://bugzilla.gnome.org/show_bug.cgi?id=776106
If for some reason we fail to probe formats (all try_fmt calls fail, for
example), this is not a critical error, but we end up with an empty list
of interlace modes. This causes all subsequent negotiation to fail.
This patch fixes interlace-mode setting to be skipped if we failed to
detect any.
https://bugzilla.gnome.org/show_bug.cgi?id=775702
These can be called from different threads and both manipulate the
pool->buffers array. Lock them properly and let flush_stop move the
array contents into a temporary array on the stack to avoid having
to call release_buffer under the object lock.
https://bugzilla.gnome.org/show_bug.cgi?id=775015
If the pool is inactive, it is guaranteed to also be flushing, so the
following check will return GST_FLOW_FLUSHING anyway.
This can happen if a v4l2src is blocking on DQBUF in create and is sent
an EOS event on another thread. In that case the pool is set to
flushing/inactive without locking, the v4l2src is unblocked, and may
call pool_process with a valid buffer on the already inactive pool.
https://bugzilla.gnome.org/show_bug.cgi?id=775014
I've seen problems where the `bytesused` field of `v4l2_buffer` would be
a silly number causing the later call to:
gst_memory_resize (group->mem[i], 0, group->planes[i].bytesused);
to result in this error to be printed:
(pulsevideo:11): GStreamer-CRITICAL **: gst_memory_resize: assertion 'size + mem->offset + offset <= mem->maxsize' failed
besides causing who-knows what other problems.
We make the assumption that this buffer has still been dequeued correctly
so just clamp to a valid size so downstream elements won't end up in
undefined behaviour.
The invalid `v4l2_buffer` I saw from my capture device was:
buffer = {
index = 0,
type = 1,
bytesused = 534748928, // <- Invalid
flags = 8260, // V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC | V4L2_BUF_FLAG_ERROR | V4L2_BUF_FLAG_DONE
field = 01330, // <- Invalid
timestamp = {
tv_sec = 0,
tv_usec = 0
},
timecode = {
type = 0,
flags = 0,
frames = 0 '\000',
seconds = 0 '\000',
minutes = 0 '\000',
hours = 0 '\000',
userbits = "\000\000\000"
},
sequence = 0,
memory = 2,
m = {
offset = 3537219584,
userptr = 140706665836544, // Could be nonsense, not sure
planes = 0x7ff8d2d5b000,
fd = -757747712
},
length = 2764800,
reserved2 = 0,
reserved = 0
}
This is from gdb with my own annotations added.
This was with gst-plugins-good 1.8.1, a Magewell XI100DUSB-HDMI video
capture device and kernel 3.13 using a dodgy HDMI cable which is great at
breaking HDMI capture devices. I'm using io-mode=userptr and have built
gst-plugins-good without libv4l.
https://bugzilla.gnome.org/show_bug.cgi?id=769765
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
Both work with autotools but they definitely don't mean the same thing, cause
problems with other build systems, and are bad form. Existence should always be
checked with #ifdef or #if defined.
The type detection would lead to assertion as it would try
to create a device without having found any type for it. It
also didn't detect MPLANE devices properly.
The monitor sets the object->element object as a GstObject. This
works for debug traces, but will assert for ELEMENT_ERROR. This
was the only case where that could happen. Add a check for that.
After switching to using V4L2_CAP_DEVICE_CAPS we lost support for
multiplanar device types. After some research, it looks like
vcap.capabilities treated the multiplanar flag of output and capture
devices equally, but not the new device_caps.
https://bugzilla.gnome.org/show_bug.cgi?id=768195
A typo in gst_v4l2_probe_and_register() caused a build error when building
with --enable-v4l2-probe. Fixing it.
gstv4l2.c: In function 'gst_v4l2_probe_and_register':
gstv4l2.c:150:25: error: 'struct v4l2_capability' has no member named 'capabilitites'
device_caps = vcap.capabilitites;
The same physical device can export multiple devices. In
this case, the capabilities field now contains a union of
all caps available from all exported V4L2 devices alongside
a V4L2_CAP_DEVICE_CAPS flag that should be used to decide
what capabilities to consider. In our case, we need the
ones from the exported device we are using.
https://bugzilla.gnome.org/show_bug.cgi?id=768195
gst_v4l2_clear_error() doesn't work like g_clear_error(), it
doesn't NULLify the pointer, so set freed debug string to NULL
so it doesn't get freed again if gst_v4l2_clear_error() is
called twice on the error.
CID 1362901
Instead of completely getting rid of the input buffer, copy
the metadata, the flags and the timestamp into an empty buffer.
This way the decoder base class can copy that information again
to the output buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=758424
This is to allow returning an error that can easily be sent as
message to the application if the element needs it. Using this
also allow ignoring errors.
https://bugzilla.gnome.org/show_bug.cgi?id=766172
v4l2src will renegotiate only if the format have changed. As of now,
it's not possible to change the allocationw without resetting the
camera. To avoid unwanted side effect, simply keep the old allocation
if no renegotiation is taking place. This fixes assertion and possible
failures in USERPTR or DMABUF import mode (when using downstream pools).
https://bugzilla.gnome.org/show_bug.cgi?id=754042
To change pixel aspect ratio from DAR to PAR, the necessary scaling factor
is DAR/PAR, not DAR*PAR.
For good measure, add debug output similar to the fixed-width and
fixed-height cases.
https://bugzilla.gnome.org/show_bug.cgi?id=766711
Instead of relying on the default colorimetry chosen by
gst_video_info_set_format(), set info.colorimetry from the
values returned by G_FMT. This allows decoders to propagate
their input colorimetry downstream.
https://bugzilla.gnome.org/show_bug.cgi?id=766383
Move the extraction of colorimetry parameters from struct v4l2_format and the
setting of the identity matrix for RGB formats into the function to avoid code
duplication.
https://bugzilla.gnome.org/show_bug.cgi?id=766383
gst_v4l2_probe_caps() returns the coded size, not the visible size. Subtract
the known padding from probed caps with the coded size before using them as
filter for caps negotiation with downstream elements.
https://bugzilla.gnome.org/show_bug.cgi?id=766382
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 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.
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
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
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
