Re: [Query] About NV12 pixel format support in a subdevice

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

 



On Sat, 7 Apr 2012, Aguirre, Sergio wrote:

> Hi Guennadi,
> 
> On Sat, Apr 7, 2012 at 4:51 PM, Guennadi Liakhovetski
> <g.liakhovetski@xxxxxx> wrote:
> > On Sat, 7 Apr 2012, Aguirre, Sergio wrote:
> >
> >> Hi Guennadi,
> >>
> >> Thanks for your reply.
> >>
> >> On Sat, Apr 7, 2012 at 4:21 PM, Guennadi Liakhovetski
> >> <g.liakhovetski@xxxxxx> wrote:
> >> > Hi Sergio
> >> >
> >> > On Sat, 7 Apr 2012, Aguirre, Sergio wrote:
> >> >
> >> >> Hi everyone,
> >> >>
> >> >> I'll like to request for your advice on adding NV12 support for my omap4iss
> >> >> camera driver, which is done after the resizer block in the OMAP4 ISS ISP
> >> >> (Imaging SubSystem Image Signal Processor).
> >> >>
> >> >> So, the problem with that, is that I don't see a match for V4L2_PIX_FMT_NV12
> >> >> pixel format in "enum v4l2_mbus_pixelcode".
> >> >>
> >> >> Now, I wonder what's the best way to describe the format... Is this correct?
> >> >>
> >> >> V4L2_MBUS_FMT_NV12_1X12
> >> >>
> >> >> Because every pixel is comprised of a 8-bit Y element, and it's UV components
> >> >> are grouped in pairs with the next horizontal pixel, whcih in combination
> >> >> are represented in 8 bits... So it's like that UV component per-pixel is 4-bits.
> >> >> Not exactly, but it's the best representation I could think of to
> >> >> simplify things.
> >> >
> >> > Do I understand it right, that your resizer is sending the data to the DMA
> >> > engine interleaved, not Y and UV planes separately, and it's only the DMA
> >> > engine, that is separating the planes, when writing to buffers? In such a
> >> > case I'd use a suitable YUV420 V4L2_MBUS_FMT_* format for that and have
> >> > the DMA engine convert it to NV12, similar to what sh_mobile_ceu_camera
> >> > does.
> >>
> >> No, it actually has 2 register sets for specifying the start address
> >> for each plane.
> >
> > Sorry, what "it?" The DMA engine, right? Then it still looks pretty
> > similar to the CEU case to me: it also can either write the data
> > interleaved into RAM and produce a YUV420 format, or convert to NV12.
> > Which one to do is decided by the format, configured on the video device
> > node by the driver.
> 
> Hmm, ok. I think I know what you mean now, sorry.
> 
> So you're saying I should really use, say: V4L2_MBUS_FMT_YUYV8_1_5X8 as
> subdevice format, and let the v4l2 device output node either use:
> 
> - V4L2_PIX_FMT_NV12
> or
> - V4L2_PIX_FMT_YUV420
> 
> depending on how I want the DMA engine to organize the data.
> 
> Did I got your point correctly?

Yes, that's what I meant. Sorry for not explaining properly:-)

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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