mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-08 08:25:33 +00:00
f4852a2d8b
Certain V4L2 drivers can report that a video receiver is seeing some signal, but that it is unable to synchronize to it. IOW: the driver can sometimes report V4L2_IN_ST_NO_SYNC and not report V4L2_IN_ST_NO_SIGNAL. In particular, I've seen the tc358743 (HDMI-to-CSI2 converter) driver sometimes report this when deployed to a fleet of embedded Raspberry Pis. The relevant kernel code is in [1]. The video output is not practically usable when V4L2_IN_ST_NO_SYNC is reported (only visually corrupted frames, sometimes with random "snow", are received). I assume that this happens when either the HDMI cable is poorly plugged in or damaged or when a CSI2 FFC cable is used and is damaged. The change in this commit is useful for detecting this working-but-not-really condition in application code. Applications already listening for the "Signal lost" message will gain the ability to handle this condition. There seem to be more V4L2 error flags like this, see [2]. However, I do not have practical experience with them and adding only V4L2_IN_ST_NO_SYNC seems like a safer option. [1]: https://github.com/raspberrypi/linux/blob/be8498ee21aa/drivers/media/i2c/tc358743.c#L1534 [2]: https://www.kernel.org/doc/html/v6.6/userspace-api/media/v4l/vidioc-enuminput.html Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7027> |
||
|---|---|---|
| .. | ||
| ext | ||
| gstv4l2.c | ||
| gstv4l2allocator.c | ||
| gstv4l2allocator.h | ||
| gstv4l2bufferpool.c | ||
| gstv4l2bufferpool.h | ||
| gstv4l2codec.c | ||
| gstv4l2codec.h | ||
| gstv4l2colorbalance.c | ||
| gstv4l2colorbalance.h | ||
| gstv4l2deviceprovider.c | ||
| gstv4l2deviceprovider.h | ||
| gstv4l2element.c | ||
| gstv4l2elements.h | ||
| gstv4l2fwhtenc.c | ||
| gstv4l2fwhtenc.h | ||
| gstv4l2h263enc.c | ||
| gstv4l2h263enc.h | ||
| gstv4l2h264codec.c | ||
| gstv4l2h264codec.h | ||
| gstv4l2h264enc.c | ||
| gstv4l2h264enc.h | ||
| gstv4l2h265codec.c | ||
| gstv4l2h265codec.h | ||
| gstv4l2h265enc.c | ||
| gstv4l2h265enc.h | ||
| gstv4l2jpegenc.c | ||
| gstv4l2jpegenc.h | ||
| gstv4l2mpeg2codec.c | ||
| gstv4l2mpeg2codec.h | ||
| gstv4l2mpeg4codec.c | ||
| gstv4l2mpeg4codec.h | ||
| gstv4l2mpeg4enc.c | ||
| gstv4l2mpeg4enc.h | ||
| gstv4l2object.c | ||
| gstv4l2object.h | ||
| gstv4l2radio.c | ||
| gstv4l2radio.h | ||
| gstv4l2sink.c | ||
| gstv4l2sink.h | ||
| gstv4l2src.c | ||
| gstv4l2src.h | ||
| gstv4l2transform.c | ||
| gstv4l2transform.h | ||
| gstv4l2tuner.c | ||
| gstv4l2tuner.h | ||
| gstv4l2videodec.c | ||
| gstv4l2videodec.h | ||
| gstv4l2videoenc.c | ||
| gstv4l2videoenc.h | ||
| gstv4l2vidorient.c | ||
| gstv4l2vidorient.h | ||
| gstv4l2vp8codec.c | ||
| gstv4l2vp8codec.h | ||
| gstv4l2vp8enc.c | ||
| gstv4l2vp8enc.h | ||
| gstv4l2vp9codec.c | ||
| gstv4l2vp9codec.h | ||
| gstv4l2vp9enc.c | ||
| gstv4l2vp9enc.h | ||
| meson.build | ||
| README | ||
| tuner.c | ||
| tuner.h | ||
| tunerchannel.c | ||
| tunerchannel.h | ||
| tunernorm.c | ||
| tunernorm.h | ||
| v4l2-utils.c | ||
| v4l2-utils.h | ||
| v4l2_calls.c | ||
v4l2 plugins
============
The idea is a bit the same as the idea for the v4l1 plugins. We want
one generic v4l2element, and a few child objects (probably only two:
v4l2src and v4l2sink):
/-------- v4l2src
v4l2element ---=
\-------- v4l2sink
Both v4l2src and v4l2sink have a uncompressed and a compressed
recording-/playback-mode. Since this is all part of v4l2, the 'client'
of these elements, i.e. an application using v4l2src/v4l2sink, will
hardly notice this. All capsnego stuff is done inside, and the plugin
knows which formats are compressed and which are not.
Please note that the v4l1 and the v4l2 plugins are *not* compatible
concerning properties. Naming has been kept the same where possible,
but in some cases, properties had to be removed or added to make
full use of v4l2.
V4L2 API: http://linux.bytesex.org/v4l2/.
http://v4l2spec.bytesex.org/
/usr/include/linux/videodev2.h or
Kernel patches available from
http://dl.bytesex.org/patches/.
Articles:
http://lwn.net/Articles/203924/