public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Erik Andrén" <erik.andren@gmail.com>
Cc: Hans de Goede <j.w.r.degoede@hhs.nl>, linux-media@vger.kernel.org
Subject: Re: libv4l, yuv420 and gspca-stv06xx conversion
Date: Wed, 25 Mar 2009 11:15:51 +0100	[thread overview]
Message-ID: <49CA0457.1090708@redhat.com> (raw)
In-Reply-To: <49C7E5A1.9010501@gmail.com>



On 03/23/2009 08:40 PM, Erik Andrén wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Hans,
> I'm trying to get gstreamer and the yuv420 format conversion in
> libv4l to play nice with the gspca-stv06xx driver. Currently this is
> not working.
>
> The resolution of the vv6410 sensor is 356*292 pixels and the native
> format of the camera is V4L2_PIX_FMT_SGRBG8.
> This produces a total image size of 103952 bytes which gets page
> aligned to 106496.
>
> When requesting to conversion to yuv420 in gstreamer I launch
> gst-launch with the following parameters:
> gst-launch-0.10 -v v4l2src queue-size=4 ! ffmpegcolorspace ! xvimageink
>
> gstreamer then proceeds with complaining that it received a frame of
>   size 155928 bytes but it expected a frame of size 156512 bytes.
>
> The delivered 155928 size seems sane as 155928 / 356 gives 438 and
> 155928 / 292 gives 534.
>
> Furthermore, the difference between the received size and the
> expected size is 584 bytes which is 2x the height.
>
> Anyhow, I hacked libv4l2.c and padded the frame with 584 in order to
> acheive the requested 156512 bytes. This worked and yielded the
> attached image.
>
> I'm currently at loss what's the root cause of this.
>
> Could the page align interfer somehow with the frame size?
> What's the correct image size? The converted image is clearly correct.
>

I think that something in the gstreamer stack expect the U and V planes of
the YUV planar data, to have each line start 32 bit word aligned. So they
expect us to add 2 bytes of padding after each line of U and V data.

That would give us 2 x (292 / 2) extra bytes for the U and for the V plane,
so 2 x (2 x (292 / 2)) = 584 bytes of additional data, and would also
explain the color banding in the image you've attached.

Now the question is, is gstreamer right in assuming this padding?

The v4l2 standard is pretty clear on this:
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/c2030.htm#V4L2-PIX-FORMAT

And then the bytesperline description, clearly says the what gstreamer expects is wrong.
But what is normal for other YUV420 planar data producing sources?

Regards,

Hans

  reply	other threads:[~2009-03-25 10:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-23 19:40 libv4l, yuv420 and gspca-stv06xx conversion Erik Andrén
2009-03-25 10:15 ` Hans de Goede [this message]
2009-03-27  9:36   ` Erik Andrén

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=49CA0457.1090708@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=erik.andren@gmail.com \
    --cc=j.w.r.degoede@hhs.nl \
    --cc=linux-media@vger.kernel.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