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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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.

Ideas? Comments?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux