hi, is there an API to ask /dev/video<N> how many frames it has produced?
context: I have a gstreamer pipe running on /dev/video0, but I need to monitor the fps to detect sensor problems
sailus: Did you read the message of mine from Wednesday about the led flash device not showing up?
Now I think that the sun6i_csi driver can't handle flash devices yet or something because there's a patch from 2015 adding support for v4l2-flash devices in the exynos4-is driver where I believe sun6i_csi is the equivalent for allwinner chips
Hmm that one was never merged
lucaceresoli: i guess you could take a look at buffer sequence.
ezequielg: do you mean __u32 sequence in struct vb2_v4l2_buffer? the problem is that I don't "own" to code that dequeues the buffers, gstreamer does it. In my code I just want to monitor the v4l2 video node
if it's just for debugging, then i guess you could add a tee and then fpsdisplaysink
ezequielg: btw in the meantime I found a solution that is OK for my needs: I have a gst 'identity' element just after the v4l2src, it emits a signal at each frame
ezequielg: it's not for debugging. my application needs to always monitor the sensor, which could stop emitting frames at any moment :\
right. even if not for debugging, fpsdisplaysink could be used (i guess, i haven't used it like this), by using the signal callback it exposes.
or if you need anything else, enhance fpsdisplaysink.
ezequielg: not sure, but I suspect that if v4l2src stop producing frames, then fpsdisplaysink will stop calling my callback, and I won't receive a "fps=0" event. right?
ezequielg: with identity I just rely on the callback being called to increment a frame counter, and then I poll the counter every second or so
ezequielg: I could so the same with fpsdisplaysink, but why using a more complex plugin to do the same thing?
lucaceresoli: makes sense :-)
i wonder if v4l2src won't emit any timeout signal.
ezequielg: :-O let me check
it doesn't i think.
ezequielg: exactly, it doesn't
maybe ndufresne knows a more elegant way. the identity doesn't sound too bad, tbh.
lucaceresoli, a more lightweight monitoring method is to install a pad probe ont he v4l2src pad
you'll be called back each time, on top of this, you can look at GstBuffer.offset to find wholes, this follow the sensor sequence, with an exception that it may be reset to 0 if you do fancy things on your pipeline
If drops is all you care about, v4l2src will push an EOS message whenever there was a whole, what's missing though is a timeout to push wholes while it's completely stopped
lucaceresoli, a better approach of course would be a v4l2 event that gives us the connection state, I think some poeple are working on this for SDI and/or HDMI
ndufresne, ezequielg: (I'm learning lots of things today, thanks!)
ndufresne: I'm looking into pad probes, didn't know about them
lucaceresoli: does the sensor knows about this state? i mean, can you produce an event from the sensor? i guess not, but ...
ndufresne: so if I do gst_pad_add_probe(pad, GST_PAD_PROBE_TYPE_BUFFER, ...) -> then my callback will be called for each buffer that goes through the pad?
in analog capture devices, we have a status ioctl.
ENUM_INPUT, iirc
but you need to poll it
ezequielg: you guess right. :( The sensor looks perfectly fine, link is OK etc, but in some cases frames stop arriving; but I can reset and reconfigure it if I detect that state
yeah.
i've done that with pci capture too.
ezequielg: if only I could detect it somehow in the driver I could handle the problem at its root (or very close)
the app would keep track of it, and kick the machine if gona bad.
i'm afraid you always have the possibility of hw going bad.
so the best place to check for this is your app.
if you haven't get frames for some time, kick the driver/thread.
if you haven't got frames for more time, reboot.
ezequielg: agreed, I don't like putting many hacks in the kernel
that's more or less what i've done on servers meant to be 24/7
ezequielg: heh, yeah, it's a great KISS algorithm, works like a charm! :)
lucaceresoli, yes, for each buffers
and this callback will be made from the v4l2src streaming thread
i know it's lame, but it's how i've dealt with it - on top of gstreamer at the app level.
(e.g. don't try and change the pipeline state from there, it will likely deadlock ;-P)
ndufresne: good to know! thanks
btw, on one of our imx6 project, my colleague ended up implement a black color detector, because the signal would be lost and the IPP would keep producing frames ;-D
(that was all done with a pad probe btw)
ndufresne :-D
hverkuil: So you know, the problem was that I didn't add the "flash-leds = <&myflash>;" to the camera dt node and changing the sensor driver to use v4l2_async_register_subdev_sensor_common instead of v4l2_async_register_subdev
I'll definitely have to make a patch in the documentation describing this... I only found this out because of some git blame, git reverse log and online searches...