linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Miguel Casas-Sanchez <mcasas@chromium.org>, linux-media@vger.kernel.org
Subject: Re: Vivid test device: adding YU12
Date: Mon, 02 Feb 2015 12:13:13 +0100	[thread overview]
Message-ID: <54CF5BC9.3040501@xs4all.nl> (raw)
In-Reply-To: <CAKoAQ7=kQyJLP62iAA43aDGGnnwVS8LAQBUK-FrwWWLFF2Tm6w@mail.gmail.com>

On 01/29/2015 03:44 AM, Miguel Casas-Sanchez wrote:
> Hi folks, I've been trying to add a triplanar format to those that vivid
> can generate, and didn't quite manage :(
> 
> So, I tried adding code for it like in the patch (with some dprintk() as
> well) to clarify what I wanted to do. Module is insmod'ed like "insmod
> vivid.ko n_devs=1 node_types=0x1 multiplanar=2 vivid_debug=1"

You are confusing something: PIX_FMT_YUV420 is single-planar, not multi-planar.
That is, all image data is contained in one buffer. PIX_FMT_YUV420M is multi-planar,
however. So you need to think which one you actually want to support.

Another problem is that for the chroma part you need to average the values over
four pixels. So the TPG needs to be aware of the previous line. This makes the TPG
more complicated, and of course it is the reason why I didn't implement 4:2:0
formats :-)

I would implement YUV420 first, and (if needed) YUV420M and/or NV12 can easily be
added later.

Regards,

	Hans

> With the patch, vivid:
> - seems to enumerate the new triplanar format all right
> - vid_s_fmt_vid_cap() works as intended too, apparently
> - when arriving to vid_cap_queue_setup(), the size of the different
> sub-arrays does not look quite ok.
> - Generated video is, visually, all green.
> 
> I added as well a capture output dmesgs. Not much of interest here, the
> first few lines configure the queue -- with my few added dprintk it can be
> seen that the queue sizes are seemingly incorrect.
> 
> If and when this part is up and running, I wanted to use Vivid to test
> dma-buf based capture.
> 
> Big thanks!
> 


  reply	other threads:[~2015-02-02 11:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29  2:44 Vivid test device: adding YU12 Miguel Casas-Sanchez
2015-02-02 11:13 ` Hans Verkuil [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-02-02 22:32 Miguel Casas-Sanchez
2015-02-03 10:10 ` Hans Verkuil
     [not found] <CAKoAQ7=MmJZcyGZkJwUFHL=yHZfG0AbNcZV+Ho0d6EhB5WV7nw@mail.gmail.com>
2015-02-04  7:20 ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54CF5BC9.3040501@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=mcasas@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).