- 25 Feb, 2014 2 commits
-
-
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 -
Nicolas Dufresne authoredDecoders or other devices that expose a minimum buffers required produce an first output. We use this information to calculate latency. https://bugzilla.gnome.org/show_bug.cgi?id=722128
-
- 14 Jan, 2014 1 commit
-
-
- 10 Jan, 2014 32 commits
-
-
-
-
Nicolas Dufresne authored
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
-
-
-
Nicolas Dufresne authored
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
-
Nicolas Dufresne authored
This function is not used anymore outside v4l2object. 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
-
-
-
-
-
-
-
Nicolas Dufresne authored
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
-
-
-
-
Nicolas Dufresne authored
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
-
Nicolas Dufresne authored
Now that we have a stride array, we should extrapolate only when eeded (non multi-planar buffer). https://bugzilla.gnome.org/show_bug.cgi?id=720568
-
-
Nicolas Dufresne authored
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
-
-
Nicolas Dufresne authored
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
-
Nicolas Dufresne authored
Most M2M have undefined behaviour initially when VIDIOC_G_FMT is called. https://bugzilla.gnome.org/show_bug.cgi?id=720568
-
-
Nicolas Dufresne authored
This is to allow adding a second io-mode property on M2M device like decoder so input and output can be controlled separatly. https://bugzilla.gnome.org/show_bug.cgi?id=720568
-
This way we can activate deactivate those quirks all at once at one place. https://bugzilla.gnome.org/show_bug.cgi?id=720568
-
V4L2_PIX_FMT_H264 is documentated as byte-stream (with start code). The ensure proper negotiation with element like h264parse. https://bugzilla.gnome.org/show_bug.cgi?id=720568
-
Nicolas Dufresne authored
This is need to correctly expose capabilities on specialized devices like decoders and encoders. https://bugzilla.gnome.org/show_bug.cgi?id=720568
-
- 03 Jan, 2014 1 commit
-
-
- 04 Dec, 2013 1 commit
-
-
Julien Isorce authored
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: https://github.com/torvalds/linux/commit/f8f3914cf922f5f9e1d60e9e10f6fb92742907ad 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
-
- 25 Nov, 2013 1 commit
- 21 Nov, 2013 1 commit
-
-
A different device with different caps may be used for the next open. https://bugzilla.gnome.org/show_bug.cgi?id=712611
-
- 18 Nov, 2013 1 commit
-
-
Tim-Philipp Müller authored
And some gtk-doc markup fixes.
-
