Unlike former definitions of LOG_CAPS, the current implementation simply
expands to GST_DEBUG_OBJECT. The LOG_CAPS macro is rarely used and most
uses duplicate already existing GST_DEBUG_OBJECT lines. Therefore, the
caps are often printed twice which unnecessarily clutters the debug log.
Replace LOG_CAPS calls with GST_DEBUG_OBJECT, remove LOG_CAPS calls, and
delete the definition of LOG_CAPS.
https://bugzilla.gnome.org/show_bug.cgi?id=776899
This goal of this allocator is mainly to allow tracking the memory.
Currently, when a buffer memory has been modified, the buffer and it's
memory is disposed and lost until the stream is restarted.
This makes it possible to set any controls that can be set with
VIDIOC_S_CTRL.
The controls are set when the property is set (if the device is open)
and when the device is opened.
https://bugzilla.gnome.org/show_bug.cgi?id=698837
Move the configuration of the framerate to where we set the other format
parameters.
Remove hack to check if the device is active.
Store streamparm in the device info.
Use some macros to access the current device configuration.
Remove some duplicate fields in src and sink and use the device configuration
instead.
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
This also does the following changes:
(1) pull the bufferpool code out into gstv4l2bufferpool.c, and make a
bit more generic so it can be used both for v4l2src and v4l2sink
(2) move some of the device probing/configuration/caps stuff into
gstv4l2object.c so it does not have to be duplicated between
v4l2src and v4l2sink
Fixes bug #590280.
Original commit message from CVS:
Some changes proposed by wingo in bug #338818 (but not everything yet). Patch from Martin Rubli to fix framerate detection.
Original commit message from CVS:
Some interface implementations for video4linux/video4linux2 plugins:
* a Tuner interface, with which one can select inputs and stations. Audio
work is underway here, but unfinished.
* A Xoverlay interface with which one can do simple overlay. Similar to
the API of the v4l/Xv XFree86 extension. Widget implementation for
GTK-2.0 coming up in the sandbox.
* Colorbalance - for adapting colors (brightness, contrast, etc.) - pretty
basic and maybe somewhat overdesigned. But it'll do for now.
Apart from these interfaces, there's also a loadable library 'xwindowlistener'
that listenes to X for the movement of a window and the overlap of other
windows. This is partly copied from xawtv (and thus partly GPL :(), but it's
needed for the xoverlay interface implementation in the v4l/v4l2 elements.
Lastly, some small changes to remove redundant properties from the v4l/v4l2
elements since these can be done much simpler. Comments appreciated!
Original commit message from CVS:
v4l plugins:
* add open/close signals
v4l2 plugins:
* add open/close signals
* move source format enumeration from v4l2element to v4l2src
* adapt to the final v4l2 API in kernel 2.5 (patches for 2.4 on http://bytesex.org/patches)
* small tweaks
Original commit message from CVS:
this adds video4linux2 source and element plugins. The division in v4l2* plugins is the same as for v4l1 - i.e. an element, a src and a sink, but there won't be separate encoding plugins (like v4lmjpegsrc) - all functionality is (thanks to video4linux2) integrated in one plugin: v4l2src. v4l2sink is still to be done, that'll come later.
