Re: Capturing video and still images using one driver
Robert Jarzmik <[email protected]>
| Newsgroups | gmane.comp.video.video4linux |
|---|---|
| Message-ID | <[email protected]> |
Guennadi Liakhovetski <[email protected]> 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:[email protected]?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list