Hi Divneil,
On 05/07/14 11:37, Divneil Wadhawan wrote:
> Hi,
>
>
> I have a driver which is MUXING out data taking in multiple inputs.
>
> It has been found in certain cases, at the minimum 40 buffers are
> required to be queued before it could MUX out anything.
>
> Currently, VIDEO_MAX_FRAME is restricting the max size to 32. This
> can be over-ridden in driver queue_setup, but, it is making it
> mandatory to use always a particular count. So, it takes the
> independence from application to allocate any count> 32.
>
> So, is it okay to revise this limit or introduce a new queue->depth
> variable which could be used in conjuction with VIDEO_MAX_FRAME to
> determine the num_buffers.
Hmm, I always wondered when this would happen.
The right approach would be to add a VB2_MAX_FRAME define to videobuf2-core.h
and use that in any v4l2 driver that uses videobuf2. VIDEO_MAX_FRAME
really shouldn't be in a public API, but I don't think we can remove it
since it's been there for ages.
The maximum number of frames is really a property of vb2 (and the older
videobuf, but I don't want to tamper with that) and as such it would be
no problem increasing it to 64.
In theory we could make the number of maximum frames driver specific, but
it would be more trouble than it's worth at the moment IMHO.
If we ever get drivers that need more than 64 buffers, then we can
always reconsider.
Which driver are you using? Is it something that you or someone else is
likely to upstream to the linux kernel?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
