Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management

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

 



Guennadi Liakhovetski wrote:
> On Tue, 26 Jul 2011, Hans Verkuil wrote:
> 
>> On Tuesday, July 26, 2011 13:44:28 Sakari Ailus wrote:
>>> Hi Hans and Guennadi,
>>
>> <snip>
>>
>>>> I realized that it is not clear from the documentation whether it is possible to call
>>>> VIDIOC_REQBUFS and make additional calls to VIDIOC_CREATE_BUFS afterwards.
>>>
>>> That's actually a must if one wants to release buffers. Currently no other
>>> method than requesting 0 buffers using REQBUFS is provided (apart from
>>> closing the file handle).
>>
>> I was referring to the non-0 use-case :-)
>>
>>>> I can't remember whether the code allows it or not, but it should be clearly documented.
>>>
>>> I would guess no user application would have to call REQBUFS with other than
>>> zero buffers when using CREATE_BUFS. This must be an exception if mixing
>>> REQBUFS and CREATE_BUFS is not allowed in general. That said, I don't see a
>>> reason to prohibit either, but perhaps Guennadi has more informed opinion
>>> on this.
>>  
>> <snip>
>>
>>>>>>> Future functionality which would be nice:
>>>>>>>
>>>>>>> - Format counters. Every format set by S_FMT (or gotten by G_FMT) should
>>>>>>>   come with a counter value so that the user would know the format of
>>>>>>>   dequeued buffers when setting the format on-the-fly. Currently there are
>>>>>>>   only bytesperline and length, but the format can't be explicitly
>>>>>>>   determined from those.
>>>>
>>>> Actually, the index field will give you that information. When you create the
>>>> buffers you know that range [index, index + count - 1] is associated with that
>>>> specific format.
>>>
>>> Some hardware is able to change the format while streaming is ongoing (for
>>> example: OMAP 3). The problem is that the user should be able to know which
>>> frame has the new format.
> 
> How exactly does this work or should it work? You mean, you just configure 
> your hardware with new frame size parameters without stopping the current 
> streaming, and the ISP will change frame sizes, beginning with some future 
> frame? How does the driver then get to know, which frame already has the 

That's correct.

> new sizes? You actually want to know this in advance to already queue a 
> suitably sized buffer to the hardware?

The driver knows that since it has configured the hardware to produce
that frame size.

The assumption is that all the buffers have suitable size for all the
formats. This must be checked by the driver, something which also must
be taken into account.

-- 
Sakari Ailus
sakari.ailus@xxxxxx
--
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