Re: Capturing video and still images using one driver

[Robert Jarzmik <robert.jarzmik@free.fr>]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> 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.

Cheers.

--
Robert

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list