Hi All, I'm working on a video capture driver (my first) for a custom board, and I have a few questions about handling 'overflow' conditions (when the application doesn't get back in time to de-queue every frame). I know that one way to avoid this is to allocate additional frame buffers, but I'm thinking about conditions where even this doesn't provide enough of a FIFO. It looks to me (from studying the videobuf2 code), that if the buffers all fill up (they all end up on the 'done' list), and then the application 'comes back' and starts de-queuing buffers, it will get the OLDEST one first, and then, the newer buffers will be returned, in the order they were originally captured. For some (most?) applications, this is probably what is best, as frames only get dropped when they have to, i.e., when the FIFO overflows, and the app sees the maximum number of frames. But what about applications that always want to see the 'newest' buffer, even if some frames are dropped? What I would like to do is write my driver such that if a new frame is captured before the app has de-queued an earlier frame, the older capture buffer would be removed from the done list and re-queued to the h/w (it's already still on the queued list, I think). The done list would then always contain only 1 frame, and it would be the newest frame captured (and the capture hardware would never run out of capture buffers to use). I think this would be OK as far as the API is concerned - the app shouldn't expect that the buffers will necessarily be returned in the order they were queued, right? So here are the questions: 1. Does this make sense, or am I wanting to do something that isn't reasonable (or do I not understand the framework)? 2. Is there any way to do this within the current videobuf2 framework? 3. If not, do you have any suggestions on changes to make this possible? I'm thinking that we would need a new function that would be called (probably from an ISR, just before calling vb2_buffer_done on the new buffer) that would remove the older buffer from the done queue, re-increment the 'queued_count', and call the 'buf_queue' function provided by the driver to re-queue the older buffer to the h/w. Am I missing anything? Thanks, Rick -- 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
