On 11/19/2010 6:22 AM, Laurent Pinchart wrote: > Hi Guennadi, > > On Friday 19 November 2010 15:15:11 Guennadi Liakhovetski wrote: >> On Fri, 19 Nov 2010, Laurent Pinchart wrote: >>> On Friday 19 November 2010 14:42:31 Hans Verkuil wrote: >>>> On Friday 19 November 2010 14:26:42 Laurent Pinchart wrote: >>>>> Some buggy sensors generate corrupt frames when the stream is >>>>> started. This new operation returns the number of corrupt frames to >>>>> skip when starting the stream. >>>> Looks OK, but perhaps the two should be combined to one function? >>> I'm fine with both. Guennadi, any opinion ? >> Same as before;) I think, there can be many more such "micro" parameters, >> that we'll want to collect from the sensor. So, if we had a good idea - >> what those parameters are like, we could implement just one API call to >> get them all, or even just pass one object with this information - if it >> is constant. If we don't have a good idea yet, what to expect there, it >> might be best to wait and first collect a more complete understanding of >> this kind of information. > A few days late on this, but I wanted to add my two cents. When using V4L2 for still photography applications (like what's done on the N900, or on our custom Frankencamera), it becomes a lot more important to know what data is good or bad, when typically you capture only one or a few frames at a high resolution, before dropping back down to a viewfinding mode. One doesn't want to throw any frames on the floor if it isn't absolutely neccessary ( 100 ms extra shutter lag for every frame you have to drop, on the N900). So having some reasonable way to know when the data becomes good is very helpful. Sensor data sheets are also often rather vague, and state things like changing regions of interest, digital zoom, etc, 'may cause a bad frame'. It'd be great if once somebody figures out what 'may' translates to, not everyone has to figure it out again for every application. Eino-Ville Talvala Stanford University -- 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
