Hi, I have a question that why we must check "icf->vb_vidq.bufs[0]" in s_fmt_vid_cap()? The application mainly calling sequence at switching fmt could be like this: streamoff s_fmt_vid_cap request_buf qbuf...qbuf streamon qbuf/dqbuf ... The application should also aware that they are switching the fmt, so they should release their buffer(per in usrptr method), and re-call request-buf/qbuf, so based on this assumption, how about we check "bufs[0]" in request_buf or qbuf according to the new fmt, if we find the buffer size is not correct, then indicate error in request_buf or qbuf. However,in s_fmt_vid_cap, we only need to check whether streaming is on/off, if it is still on, that means HW resource is not available or IO/buffer is in progress, then we reject s_fmt. What do you think? For the idea 3, (what is the difference between idea 1 and 3?) in our real usage cases of camera(our product is a phone), we will set many formats, such as: preview@VGA, photos@5M/3M/QVGA/QCIF..., video@1080p/720p/VGA/QVGA, if we maintain each queue for each fmt, it seems that there are too many queues, and, in this way, the application need to be changed, it should quite aware of VIDIOC_BUFQ_SELECT queue-id for each fmt, then it could allocate/release the required buffer queue by new ioctl. Is my understanding correct? Thanks! -Qing -----Original Message----- From: Guennadi Liakhovetski [mailto:g.liakhovetski@xxxxxx] Sent: 2011年2月16日 1:34 To: Linux Media Mailing List Cc: Qing Xu; Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert; Karicheri, Muralidharan; Eino-Ville Talvala Subject: [RFD] frame-size switching: preview / single-shot use-case 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/ ?韬{.n?????%??檩??w?{.n???{炳g???^n?■???h?璀?｛?夸z罐?+€?zf＂?????i?????_璁?:+v??撸?
