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.
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
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
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.
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 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
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
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
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
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
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
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.
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
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).
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.
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.
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.
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.
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.
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.
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+.
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
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
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
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
