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
