There used to be some profile/level support in encoders. This code was moved to
GstV4l2Codecs and is now also used for decoders. The caps templates for the
H.264, H.265, MPEG4, VP8 and VP9 encoders and decoders should now reflect the
profiles and levels advertised by the kernel.
First step of a larger cleanup, all function from v4l2_calls are in fact
methods on GstV4l2Object. This split makes the code really confusing.
This also remove no longer unused macros.
This implements H264 encoding support using generic V4L2 interface. It is
reported to work with Samsung MFC driver, IXM.6 CODA driver and
Qualcomm mainline Venus driver. Other platform should be supported as
none of this work is platform specific.
The implementation consist of a GstV4l2VideoEnc base class, which
implements the core streaming functionality. This base class is implemented
by GstV4l2H264Enc class that implements the caps negotiation specific to
H264 profiles and level. This implementation supports hardware with multiple
H264 encoder. Though, to make it simplier to use, the first discovered H264
encoder will be named v4l2h264enc. Other encoder found during discovery will
have a unique name like v4l2video0h264enc.
This work is the combined work of multiple developpers in the last 3
years. Thanks to all of the contributors:
Ayaka <ayaka@soulik.info>
Frédéric Sureau <frederic.sureau@vodalys.com>
Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>
Nicolas Dufresne <nicolas.dufresne@collabora.com>
Pablo Anton <pablo.anton@vodalys-labs.com>
https://bugzilla.gnome.org/show_bug.cgi?id=728438
A typo in gst_v4l2_probe_and_register() caused a build error when building
with --enable-v4l2-probe. Fixing it.
gstv4l2.c: In function 'gst_v4l2_probe_and_register':
gstv4l2.c:150:25: error: 'struct v4l2_capability' has no member named 'capabilitites'
device_caps = vcap.capabilitites;
The same physical device can export multiple devices. In
this case, the capabilities field now contains a union of
all caps available from all exported V4L2 devices alongside
a V4L2_CAP_DEVICE_CAPS flag that should be used to decide
what capabilities to consider. In our case, we need the
ones from the exported device we are using.
https://bugzilla.gnome.org/show_bug.cgi?id=768195
If something in /dev/video* get added, removed or replaced, we need to
probe the devices again in order to ensure the dynamic devices are up to
date.
https://bugzilla.gnome.org/show_bug.cgi?id=758085
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
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:
Patch by: Frederic Crozat <fcrozat@mandriva.org>
* ext/esd/gstesd.c: (plugin_init):
* ext/flac/gstflac.c: (plugin_init):
* ext/shout2/gstshout2.c: (plugin_init):
* ext/wavpack/gstwavpack.c: (plugin_init):
* sys/oss/gstossaudio.c: (plugin_init):
* sys/v4l2/gstv4l2.c: (plugin_init):
Make sure gettext returns translations in UTF-8 encoding rather
than in the current locale encoding (#546822).
