[lkml]   [2022]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v1] media: videobuf2: Allow applications customize data offsets of capture buffers

On 3/25/22 13:32, Nicolas Dufresne wrote:
> Le jeudi 24 mars 2022 à 21:20 +0300, Dmitry Osipenko a écrit :
>> The root of the problem is that DRM UAPI is more flexible and allows to
>> customize offsets for both S/MPLANEs, while V4L doesn't allow to do it
>> at all. I'm exploring all the potential options, so far neither of the
>> proposed variants is ideal.
> In GStreamer kmssink, the way DRM is used, is that if you have 2 planes in your
> pixel format, but only received 1 DMABuf, we will pass this DMABuf twice (well
> GEM handles, but twice), with appropriate offset.
> With this in mind, the idea for V4L2 could be to always resort to MPLANE for
> this purpose. The tricky part for userland is that it needs to know the dual
> pixel format and map that accordingly. That is a bit difficult and this is
> something Helen was trying to address with the v4l2_buffer_ext (that and
> allowing space to store DRM Modifiers in the future).

FYI: here is Helen's last patch series. Since Helen is no longer active in
the media subsystem, someone else who is sufficiently motivated would have to
take over.

I'm not enthusiastic about messing with data_offset: it was - in hindsight - a
bad idea.



> The second challenge is the overhead. In DRM, as we "prime" the DMABuf into
> handles, this gives a kernel object to store any relevant information about the
> buffer. So having it duplicate can be done at no cost. In V4L2, the driver would
> need to handle that more often. Specially that despite the recommendation
> (except for primary buffer decoder, were this is mandatory), we don't force a
> strict DMABuf / Buffer IDX mapping.
> Nicolas

 \ /
  Last update: 2022-05-18 12:29    [W:0.154 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site