Re: [RFD] frame-size switching: preview / single-shot use-case

[Mauro Carvalho Chehab <maurochehab@gmail.com>]

Em 15-02-2011 15:33, Guennadi Liakhovetski escreveu:
> Hi
> 
> This topic has been slightly discussed several times [1] before, but there 
> has been no conclusion, nor I'm aware of any implementation, suitably 
> resolving this problem. I've added to CC all involved in earlier 
> discussions, that I managed to find.
> 
> What seems a typical use-case to me is a system with a vewfinder or a 
> display, providing a live preview of the video data from a source, like a 
> camera, with a relatively low resolution, and a possibility to take 
> high-resolution still photos with a very short delay.
> 
> Currently this is pretty difficult to realise, e.g., with soc-camera 
> drivers you have to free the videobuf(2) queue, by either closing and 
> re-opening the interface, or by issuing an ioctl(VIDIOC_REQBUFS, 
> count=0) if your driver is already using videobuf2 and if this is really 
> working;), configure with a different resolution and re-allocate 
> videobuffers (or use different buffers, allocated per USERPTR). Another 
> possibility would be to allocate and use buffers large enough for still 
> photos, also for the preview, which would be wasteful, because one can 
> well need many more preview than still-shot buffers.
> 
> So, it seems to me, we could live with a better solution.
> 
> 1. We could use separate inputs for different capture modes and support 
> per-input videobuf queues. Advantage: no API changes required. 
> Disadvantages: confusing, especially, if a driver already exports multiple 
> inputs. The driver does not know, whether this mode is required or not, 
> always exporting 2 inputs for this purpose doesn't seem like a good idea. 
> Eventually, the user might want not 2, but 3 or more of such videobuf 
> queues.

Very bad. The high res is not a new input.
> 
> 2. Use different IO methods, e.g., mmap() for preview and read() for still 
> shots. I'm just mentioning this possibility here, because it occurred in 
> one of previous threads, but I don't really like it either. What if you 
> want to use the same IO method for all? Etc.

Can be done.
> 
> 3. Not liking either of the above, it seems we need yet a new API for 
> this... How about extending VIDIOC_REQBUFS with a videobuf queue index, 
> thus using up one of the remaining two 32-bit reserved fields? Then we 
> need one more ioctl() like VIDIOC_BUFQ_SELECT to switch from one queue to 
> another, after which setting frame format and queuing and dequeuing 
> buffers will affect this currently selected queue. We could also keep 
> REQBUFS as is and require BUFQ_SELECT to be called before it for any queue 
> except the default 0.
> 
> Yes, I know, that some video sensors have a double register set for this 
> dual-format operation, so, for them it is natural to support two queues, 
> and drivers are certainly most welcome to use this feature for, say, the 
> first two queues. On other sensors and for any further queues switching 
> will have to be done in software.

Seems too hacky to me. 

There's a 4th alternative: open the device twice, and use different settings
on each open. Userspace can stop streaming on one file descriptor and 
start the other one when he wants to take a high-res picture.

Cheers,
Mauro