[MPlayer-dev-eng] [PATCH] Fix inverted colours when capturing YV12 in V4L2 mode

Jindrich Makovicka makovick at kmlinux.fjfi.cvut.cz
Fri Dec 16 20:59:48 CET 2005


Luc Gallant wrote:
> I am using a virtual v4l2 driver that I created (ported from v4l1
> actually). I can send in whatever file type I want, and in this case I
> send in YV12/YVU420. When I send in that file type, the colours are
> inverted. When I send in I420/YUV420 and tell mplayer about this, it
> works fine...

MPlayer never asks for YV20/YVU420. So why do you send it? You'll 
obviously get inverted colours when MPlayer requests I420 and you send YV12.

> It is ok that the bt8x8 was unable to produce YV12/YVU420 natively. In
> my opinion, mplayer should try to set an image format, and if the
> driver responds with something that it doesn't have that image format,
> then too bad. In the way that mplayer is right now, if a device is
> actually sending in YV12, it will display inverted, and the user has
> to use -of swapuv or something like this.
> 
> Like it says in the code in tvi_v4l2.c, "// YV12 uses
> VIDEO_PALETTE_YUV420P, but the planes are swapped", this goes back to
> V4L1 and the fact that back then YV12 == YUV420P, which is completely
> inverted. With V4L2, it is now correct.

No, YV12 was never YUV420P. MPlayer just uses YUV420 ~ YV12 for 
convenience, because YV12 is sort of "default" colorspace, and later 
swapped the planes when copying the buffer. I might as well remove this 
code, but as long as it works and there is negligible overhead, I'd 
prefer to let it be until I hear real bugreports.

> Let me know if there are any more issues or something I missed. Thanks.

There are no issues. Everything works as expected. I only suppose that 
your driver (or just your approach) is bogus.

Regards,
-- 
Jindrich Makovicka




More information about the MPlayer-dev-eng mailing list