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
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
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
The checks were removed inadvertedly in previous patch and not replaced.
Re-introduce the configure checks and some of the checks in order to enable
this plugin again. We only check if videodev2.h exist on the platform to
avoid building on Windows or OSX, though we build against our own copy. This
was breaking the build on built-bot.
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
GetCurrentProcess/SetFrontProcess/TransformProcessType was deprecated
and now removed in Mac OSX 10.9. orderFrontRegardless is used to make
the video window the most front window.
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
And especially also consider update versions, e.g. 10.5 with updates
will be 1051 or similar and thus bigger than MAC_OS_X_VERSION_10_5 but
still won't have the API we want to use.
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
show_frame is deferred to the main thread and can be called
when the sink has been released, so we need to keep an extra ref
on ObjectiveC object helper.
https://bugzilla.gnome.org/show_bug.cgi?id=708501
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
When setting timestamps on outgoing buffers, clear the
dts explicitly, otherwise it may end up being set to a
bogus value from last time it was used. Avoids every
second or so buffer's dts being set to 0. Not that it
should matter for raw video.
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
