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

[Jindrich Makovicka]

Luc Gallant wrote:
> 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

I know what these formats are.

> According to me, it was broken and set to YUV420, causing part of the
> problem. 

If tvi_v4l* does VIDIOC_S_FMT(V4L2_PIX_FMT_YUV420) and you subsequently 
return the YVU image, you have a problem. I agree with that.

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

Grrrr... that's why the plane swapping code is there. Once more: If 
outfmt=YV12 is used, tvi_v4l* requests I420 from the card (the same when 
you used outfmt=i420), and it swaps the u/v planes when copying it. So 
everything works fine.

Or, as I see now, this is how it worked before 1.28 tvi_v4l2 commit, 
which made this hack useless because now YV12 is in fact not used even 
for output :)

So I'll probably apply your patch to make things clear.

-- 
Jindrich Makovicka