mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-28 03:00:35 +00:00
2766e4816a
We had a problem with negotiation of the framerate. Gstreamer was querying the FRAMEINTERVALS based on the max frame size instead of the desired frame size. This was resulting in non-negotiated errors when trying to run with a smaller frame size and fps higher than the max for the max image size. Fx the max framerate for 1024x1024 RGB on CMOSIS4000 is 28.292 While for 1024x100 RGB it is 280.867 But Gstreamer would allow any framerates bigger than 28.292 no matter the frame size used... I have fixed it by 1st changing the CAPS query to use the minimum frame size instead of maximum. This however has the downside of allowing gstreamer to negotiate framerates that are too high if the image size is bigger than the minimum. This is not a huge problem since our driver just CLAMPS the fps value to the max then. However gstreamer was not being properly notified of this change, and would therefore report a wrong fps in the CAPS structure. Note that the fps would be correct inside the buffer info. Since gstreamer was reading the fps back after setting it. It was just not being "propagated" to the CAPS structure. I have also added a WARNING to this point so we can see if the fps that gstreamer tries to apply was accepted or not. And the next part of the fix was to add a framerate check after the frame size has been established. I did this inside the fixate_caps function of the v4l2src, which was calling the TRY_FMT in order to check if the format was correct. So I just added a check for the ENUM_FRAMEINTERVALS in there. And now we get the non-negotiated again if the fps is too high for the selected frame size. Also added a couple of warnings so it is easy to see that this was the cause. See: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3037 Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7850> |
||
|---|---|---|
| .. | ||
| 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/