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

[Luc Gallant]

On 12/16/05, Jindrich Makovicka <makovick at kmlinux.fjfi.cvut.cz> wrote:
> Luc Gallant wrote:
> > In this case, this is my point. When I put outfmt=yv12, tvi_v4l2 requests
> > this format from my driver, and my driver agrees to send it in.
>
> No. MPlayer requests fcc_mp2vl(IMGFMT_YV12), which is V4L2_PIX_FMT_YUV420.
>
In the V4L2 API Spec, it says that V4L2_PIX_FMT_YVU420  == ('YV12')
http://v4l2spec.bytesex.org/spec-single/v4l2.html

According to me, it was broken and set to YUV420, causing part of the
problem. Now, YV12 and I420 are distinct formats. There is a part in
the patch that resets this. Basically, in the mplayer code, because of
the following statements in different parts of the code:

     case V4L2_PIX_FMT_YUV420:	return IMGFMT_I420;

AND

    case IMGFMT_YV12:	return V4L2_PIX_FMT_YUV420;

YV12 was defined as equaling I420, which to me is a problem.




> However,
> > when I send in the format, the U and V planes were being switched in memory,
> > which was causing the colours to be inverted. I know for sure that I am
> > sending in YV12 video, because if I just play this video using read() and
> > telling mplayer it's yv12 coming in, then it works fine. So, I don't know
> > what the mplayer team wants to do, but I'm saying that when using yv12, the
> > colours are inverted, and my patch stops this from happening.
>
> Please, get a real TV card and see for yourself that the colors are ok.
I don't have a TV card that sends in YV12, but if after applying the
patches the colours are inverted, then i'll accept the responsibility
and it can be reverted.

>
> > In my patch, it is only the YV12 case that I'm uncommenting. If this breaks
> > bttv driver colours, then maybe the bttv fix should be applied somewhere
> > else instead of there...
>
> The patch is mostly ok, it just fixes things which aren't broken.
>
> --
Let me know how this goes. Thanks.

Luc Gallant