- 08 May, 2014 5 commits
-
-
Nicolas Dufresne authoredThe 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.
-
Nicolas Dufresne authored
-
Nicolas Dufresne authored
The setup_format() was confusing since it does not set anything, in fact it reads the setup from the driver and save it.
-
Nicolas Dufresne authored
-
Nicolas Dufresne authored
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.
-
- 04 May, 2014 1 commit
-
-
Nicolas Dufresne authored
Instead of having each M2M class do their own probing, use the GstV4l2Iterator and probe all devices in a single pass. https://bugzilla.gnome.org/show_bug.cgi?id=727925
-
- 30 Apr, 2014 1 commit
-
-
Nicolas Dufresne authored
In v4l2 specification, RGB32 has the alpha, or pading, first, not last. See http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html . https://bugzilla.gnome.org/show_bug.cgi?id=540941
-
- 01 Apr, 2014 1 commit
-
-
Nicolas Dufresne authored
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
-
- 29 Mar, 2014 1 commit
-
-
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+.
-
- 16 Mar, 2014 1 commit
-
-
Olivier Crête authored
-
- 15 Mar, 2014 2 commits
-
-
Nicolas Dufresne authored
XV support for v4l2 never became upstream and ended up being commented out with an undef for a long time now.
-
Nicolas Dufresne authored
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
-
- 25 Feb, 2014 4 commits
-
-
VP8 doesn't require parsing (vp8parse doesn't exist, so negotiation with demux fails if "parsed" is set in caps). https://bugzilla.gnome.org/show_bug.cgi?id=724636
-
Nicolas Dufresne authored
Until GStreamer has one (see bug722760), we should not require a parser for VP8. https://bugzilla.gnome.org/show_bug.cgi?id=722128
-
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 authored
Decoders 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 23 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
-
-
