Eino-Ville Talvala wrote:
I think we have a use case for events that would require correlating
with frames, although I agree that the buffer index would be far simpler
to match with than a timestamp. The specific feature is letting the
application know exactly what sensor settings were used with a given
frame, which is essential for our slowly-developing computational camera
API, which will be changing sensor parameters on nearly every frame
boundary.
I think one event is probably sufficient to encode the relevant register
values of our sensor. Would you expect there to be any issue with
having an event happen per frame?
I do expect several events per frame from the AEWB, AF and histogram
statistics and no problems. :-)
But if I understand correctly, the registers are some kind of metadata
associated to the frame? That perhaps includes exposure time, gain etc.
The events interface would be good for this if the metadata fits to a
single v4l2_event structure. A new ioctl could be an alternative,
perhaps it could be a private ioctl first.
This is more or less comparable to the H3A statistics IMO. So the user
space gets an event and can query the H3A data.
Associating events to a single frame is slightly troublesome since a
succesful frame reception is only certain when it already has happened.
There could be a metadata event and after that a receive buffer overflow
that spoils the frame. In that case the field_count could be just
incremented without dequeueing any buffers, though.
--
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
