[FFmpeg-devel] [PATCH] avdevice/v4l2: add limited support for multiplanar API

Anton Khirnov anton at khirnov.net
Thu Jun 27 19:05:50 EEST 2024


Quoting Ramiro Polla (2024-06-27 16:13:24)
> On Tue, Jun 25, 2024 at 1:56 PM Ramiro Polla <ramiro.polla at gmail.com> wrote:
> > On Tue, Jun 25, 2024 at 11:19 AM Anton Khirnov <anton at khirnov.net> wrote:
> > > Quoting Ramiro Polla (2024-06-20 17:40:39)
> > > > This commit adds support for V4L2's multiplanar API, but only when the
> > > > number of planes is 1.
> > > >
> > > > Adding full support for the multiplanar API would require a device that
> > > > actually uses more than 1 plane, which I have not found yet.
> > >
> > > Out of curiosity, what's the point of a multiplanar API when the plane
> > > count is always one?
> >
> > Good question, and I wish I knew the answer. Some SBCs are providing
> > HDMI input through v4l2, and they decided to use the multiplanar API,
> > even though the count is always one.
> >
> > I couldn't find many examples on how to use this API correctly, with a
> > couple of implementations being buggy to a point where they will only
> > work when the count is one.
> >
> > I wish I could find a device that uses the multiplanar API and
> > actually provides more than one buffer so that I could properly test,
> > but by looking at the kernel source code I couldn't find a device that
> > I could easily obtain yet.
> 
> Is anyone fundamentally opposed to this approach to implement limited
> support for multiplanar API? I figure it could still be useful even
> when full multiplanar API support is implemented, because multiple
> memory buffers per packet will likely mean memcpy()s, which can be
> avoided if the plane count is one.

Ideally this should be turned into a lavfi source, then multiple planes
can be exported individually.

(this is not an objection to this patch)

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list