Re: Capturing video and still images using one driver
- Date: Fri, 06 Nov 2009 18:11:16 +0100
- From: Robert Jarzmik <robert.jarzmik@xxxxxxx>
- Subject: Re: Capturing video and still images using one driver
Guennadi Liakhovetski <g.liakhovetski@xxxxxx> writes:
>> What this makes me think is that a sensor could provide several "contexts" of
>> use, as :
>> - full resolution still image context
>> - low resolution still image context
>> - full resolution video context
>> - low resolution video context
> Why fixed resolutions? Just make it possible to issue S_FMT for video or
> for still imaging... That would work seamlessly with several inputs
> (S_INPUT, S_FMT...).
It's not about _fixed_ resolution. It's rather about power consumption
actually. In mt9m111 sensor, there are 2 modes : A and B. Mode A always eats
tiny amounts of power, but the output resolution is limited to 640x480 IIRC.
Mode B eats more power, but allows full resolution of 1280x1024.
As I saw it, a "context" would allow a range of resolution, a range of clock,
and maybe capability to capture a video stream or not.
What's behind the concept of "context" is : a set of capabilities the hardware
can store internally (in terms of resolution, type of output, power consumption,
etc ...). And of course a "hardware switch" to switch between setups.
>> Then, a new/existing v4l2 call would switch the context (perhaps based on buffer
>> type ?) of the sensor.
> ...on a second thought, it doesn't seem that smart to me any more to tie
> the streaming vs. still mode distinction to a specific buffer type...
I truly don't know. I'll take your word for it.
video4linux-list mailing list