Make sure we always call munmap() with the same size we called mmap()
with before.
Current v4l2src uses the same structure for VIDIOC_QUERYBUF, VIDIOC_QBUF
and v4l2_munmap calls. The problem is that the video buffer size (length)
may vary for compressed or emulated bufs. VIDIOC_QBUF will change it if
we pass the pointer of a v4l2_buffer. This is why we should avoid using
same variable for mmap and video buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=671126
Don't post a (fatal) error message on the bus just because we
failed to query some control. Fixes issue with built-in
Suyin Corp webcam for HP notebook (usbid 064e:e28a) on
OpenSuse 12.1, where querying red/blue balance fails.
https://bugzilla.gnome.org/show_bug.cgi?id=670197
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
We don't currently support setting the pixel-aspect-ratio from V4L2. So
simply set it to be 1/1 in the caps to prevent negotiation failures when
fixating to weird values (e.g. when the downstream caps has
pixel-aspect-ratio = [ MIN, MAX ] )
https://bugzilla.gnome.org/show_bug.cgi?id=663580
We used to skip frame rate setup if the camera was already setup
with the requested frame rate. This breaks some cameras though,
causing them to not output data (several models of Thinkpad cameras
have this problem at least).
So, don't skip.
https://bugzilla.gnome.org/show_bug.cgi?id=638300
Some drivers are buggy are will change the current format when
processing VIDIOC_TRY_FMT. Save and restore the current format
to ensure the format is kept unchanged.
https://bugzilla.gnome.org/show_bug.cgi?id=649067
Use the fraction compare utility to compare function, not the
handcrafted one. The handcrafted one is buggy as it doesn't take into
account rounding error. For example comparing a framerate of 20/1 on a
camera configured as 30/1 fps would yield true: 1 == (1 * 20)/30 and not
re-configure the camera. Fixes#656104
Based on a patch by Guennadi Liakhovetski.
v2: updates because I forgot to add GstTuner interface to v4l2sink
v3: update to add all possible values to norm enum
Commit 6c8268dbfd broke recording
from interlaced v4l2 source (e.g. typical tv capture card) since
V4L2_FIELD_SEQ_TB (with fields stored separately) does not map
to currently defined interlaced format (fields stored interleaved).
Besides this mismatch, hardware might quite likely not support or
appreciate this field value, since querying supported formats mapped
_INTERLACED field formats to interlaced=true caps (so the latter should
not be mapped to field value that is not known to be supported).
Older kernels don't have these, and there's no easy way to check for the
existance of enums that doesn't involve a configure check, so just define
these if the V4L2_CAP_VIDEO_OUTPUT_OVERLAY define is not there, which was
added in the same commit as the TB/BT enum. Fixes compilation on CentOS 5.
https://bugzilla.gnome.org/show_bug.cgi?id=639339
These macros will expand to NOOPs given the right defines. Also,
g_return_if_fail() and friends are meant to be used to catch programming
errors (like invalid input to functions), not runtime error handling.
Looks like this got enabled by accident when adding it to v4l2sink,
so undo this for now. Not sure it makes much sense in a GStreamer
context with current hardware.
This reverts commit 9e1d419d07.
Reverting this since it adds unreviewed and bad API to v4l2src
(property of type enum, with seemingly random and unsorted values).
output devices should use get/set output, and in either case we should
not print a warning message if the ioctl fails but the device does not
claim to support the tuner interface
If xoverlay is available, v4l2sink should create a window for the overlay to
display in.
The window automatically tries to make itself as large as possible.
This works well on a small screen, but perhaps should first attempt to use
the size of the video that is played (no scaling).
Special case check for sub-buffers: In certain cases, places like
GstBaseTransform, which might check that the buffer is writable before copying
metadata, timestamp, and such, will find that the buffer has more than one
reference to it. In these cases, they will create a sub-buffer with an offset=0
and length equal to the original buffer size.
This could happen in two scenarios: (1) a tee in the pipeline, and (2) because
the refcnt is incremented in gst_mini_object_free() before the finalize function
is called, and decremented after it returns.. but returning this buffer to the
buffer pool in the finalize function, could wake up a thread blocked in
_buffer_alloc() which could run and get a buffer w/ refcnt==2 before the thread
originally unref'ing the buffer returns from finalize function and decrements
the refcnt back to 1!
This is related to issue #545501
The size of the buffer would be zero'd out in gst_v4l2_buffer_finalize()
after the buffer is qbuf'd or pushed onto the queue of available buffers..
leaving a race condition where the thread waiting for the buffer could awake
and set back a valid size before the finalizing thread zeros out the length.
This would result that the newly allocated buffer has length of zero.
When v4l2sink goes to PAUSED->READY it only stops streaming, so the state
should be set to STATE_PENDING_STREAMON in case the element transitions
back to PLAYING.
We'd prefer to throttle the decoder if we run out of buffers, to keep a bound
on memory usage. Also, for OMAP4 it is a requirement of the decoder to not
alternate between memory alloced by the display driver and malloc'd userspace
memory.
note: this really only affects v4l2sink since gst_v4l2_buffer_pool_get() is
only called once per buffer in the v4l2src case (in
gst_v4l2src_buffer_pool_activate())
Most v4l2 drivers will get upset when you queue the same buffer twice in a
row without first dequeueing it.
Rendering of pre-roll buffers can be re-introduced later, but will require
tracking the state of the buffer, and avoiding to re-QBUF if the buffer has
already been passed to the driver.
