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.
When the decoder is using pad_alloc(), v4l2sink would behave badly if
the number of buffers ('queue-size' property) was not high enough to
account for all the buffers needed by the decoder, and other elements
(such as queues) between the decoder and v4l2sink. This patch
slightly increases the default number of buffers, and changes v4l2sink
to drop frames rather than return an error in case the number of
buffers is not high enough.
with i686-apple-darwin10-gcc-4.2.1:
gstv4l2object.c: In function 'gst_v4l2_object_get_nearest_size':
gstv4l2object.c:1988: warning: format '%u' expects type 'unsigned int', but argument 12 has type 'gint *'
gstv4l2object.c:1988: warning: format '%u' expects type 'unsigned int', but argument 13 has type 'gint *'
it's perfectly ok for a video output device to not have overlay capabilities.
this patch removes the need to get/set the overlay parameters if the user
does not explicitely request one of the overlay properties
MPEG doesn't have a static size per frame, so don't pretend it has one
and fail when capturing because it doesn't match. Instead mark the size
as unknown and let the read frame grabbing method use a reasonable fallback
value (assuming that's only for actual streaming formats)
Fixes bug #628349.
The format list should be sorted from high ranks to low ranks. In the GSList
sorting function this means the compare needs to return a positive value if
format a has a lower rank than format b.
Among other things this fixes v4l2src to prefer non-emulated formats
to emulated formats when built against libv4l.
In the case we change the State from READY_TO_NULL the buffers in the pool
still hold an open dup file descriptor to the device, therefore the device
release function will not be called and the device will probably answer with
-EBUSY when we reopen it in the next NULL_TO_READY transition.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
See bug #622500 and #612244.
This allows set_caps to succeed if caps change in a way that
would not modify the format we're getting from the hardware.
Otherwise if not in NULL state, setting caps would fail
with EBUSY.
With this change, in some cases it's OK to go PLAYING->READY->PLAYING
rather than PLAYING->NULL->PLAYING to avoid a time-consuming close
and reopen of the device.
Fixes#621723
Fixes#621723 (partially)
set_caps can fail if the video device is running, in that case
setting its format leads to EBUSY.
If set_caps fails then we will not have set up the buffer pool
(it will be NULL) which leads to a crash when we try to pull
buffers. If we fail the negotiate on set_caps failure, then we
won't go to playing state and won't crash.
This is a small improvement. Of course, a nicer fix would
be to make set_caps work in the case where the format is
unchanged. If the format has changed, failing is
probably correct because we need to close the device
(go to NULL state) in order to set caps.
