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

Luc Gallant lucgallant at gmail.com
Fri Dec 16 22:49:29 CET 2005


 

-----Original Message-----
From: mplayer-dev-eng-bounces at mplayerhq.hu
[mailto:mplayer-dev-eng-bounces at mplayerhq.hu] On Behalf Of Jindrich
Makovicka
Sent: December 16, 2005 3:49 PM
To: mplayer-dev-eng at mplayerhq.hu
Subject: Re: [MPlayer-dev-eng] [PATCH] Fix inverted colours when
capturingYV12 in V4L2 mode

Luc Gallant wrote:
> On 12/16/05, Jindrich Makovicka <makovick at kmlinux.fjfi.cvut.cz> wrote:
> 
>>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.
>>
> 
> If Mplayer never asks for YV12/YVU420, then why can you put an 
> outfmt=xxx flag in the TV options? In my specific case, I put this 
> outfmt flag in the tv options, so I expect it to ask for that. I will 
> look at the S_FMT commands issued later to see what it asks for.

>outfmt is the format tvi_v4l* produces, not necessarily the format which
goes out of the tv card. Well, there is actually only one exception, which
is 
>YV12, in order to make bt8x8 work out of the box. In all other cases outfmt
is really what tvi_v4l* requests from the card.

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. 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.

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...


Let me know wheter I am missing the entire point or if the patch is worth
applying.


Luc Gallant




More information about the MPlayer-dev-eng mailing list