mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-10-19 08:53:51 +00:00
56b1d088a9
I've seen problems where the `bytesused` field of `v4l2_buffer` would be
a silly number causing the later call to:
gst_memory_resize (group->mem[i], 0, group->planes[i].bytesused);
to result in this error to be printed:
(pulsevideo:11): GStreamer-CRITICAL **: gst_memory_resize: assertion 'size + mem->offset + offset <= mem->maxsize' failed
besides causing who-knows what other problems.
We make the assumption that this buffer has still been dequeued correctly
so just clamp to a valid size so downstream elements won't end up in
undefined behaviour.
The invalid `v4l2_buffer` I saw from my capture device was:
buffer = {
index = 0,
type = 1,
bytesused = 534748928, // <- Invalid
flags = 8260, // V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC | V4L2_BUF_FLAG_ERROR | V4L2_BUF_FLAG_DONE
field = 01330, // <- Invalid
timestamp = {
tv_sec = 0,
tv_usec = 0
},
timecode = {
type = 0,
flags = 0,
frames = 0 '\000',
seconds = 0 '\000',
minutes = 0 '\000',
hours = 0 '\000',
userbits = "\000\000\000"
},
sequence = 0,
memory = 2,
m = {
offset = 3537219584,
userptr = 140706665836544, // Could be nonsense, not sure
planes = 0x7ff8d2d5b000,
fd = -757747712
},
length = 2764800,
reserved2 = 0,
reserved = 0
}
This is from gdb with my own annotations added.
This was with gst-plugins-good 1.8.1, a Magewell XI100DUSB-HDMI video
capture device and kernel 3.13 using a dodgy HDMI cable which is great at
breaking HDMI capture devices. I'm using io-mode=userptr and have built
gst-plugins-good without libv4l.
https://bugzilla.gnome.org/show_bug.cgi?id=769765
|
||
|---|---|---|
| .. | ||
| ext | ||
| gstv4l2.c | ||
| gstv4l2allocator.c | ||
| gstv4l2allocator.h | ||
| gstv4l2bufferpool.c | ||
| gstv4l2bufferpool.h | ||
| gstv4l2colorbalance.c | ||
| gstv4l2colorbalance.h | ||
| gstv4l2deviceprovider.c | ||
| gstv4l2deviceprovider.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 | ||
| gstv4l2vidorient.c | ||
| gstv4l2vidorient.h | ||
| Makefile.am | ||
| 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_calls.h | ||
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/