Patchwork gstreamer strange distorted image.

login
register
mail settings
Submitter Dennis Han
Date Sept. 16, 2013, 8:34 p.m.
Message ID <COL125-DS131E6AB52AB93A8F11CE6187260@phx.gbl>
Download mbox | patch
Permalink /patch/58181/
State Not Applicable
Delegated to: Otavio Salvador
Headers show

Comments

Dennis Han - Sept. 16, 2013, 8:34 p.m.
I tested you patch more detail and found a problem.

In brief.

1. With original value
IC_RSZ_MAX_RESIZE_RATIO = 0x00004000
>> it's OK


2. With a new value
IC_RSZ_MAX_RESIZE_RATIO = 0x00002000
>> center pixels are overlapping


I think this patch has to be ignored.



-----Original Message-----
From: Sandoval Gonzalez Leonardo-B42214 [mailto:B42214@freescale.com] 
Sent: Monday, September 16, 2013 1:20 PM
To: Otavio Salvador
Cc: Dennis Han; meta-freescale@yoctoproject.org
Subject: RE: [meta-freescale] gstreamer strange distorted image.

Sure Otavio, I will send the correct patch soon.

Dennis, in the meantime, can you try the one below:

From 6ae2813aed1063143400de8fe111a9d9a6130a4a Mon Sep 17 00:00:00 2001
From: Oliver Brown <b37094@b37094-vmlinux.(none)>
Date: Wed, 24 Jul 2013 00:20:26 -0500
Subject: [PATCH] ENGR00272541 [IPU] -  IC_RSZ_MAX_RESIZE_RATIO should be set
to 0x2000

The max resize ratio should be set to 0x2000 (or 8192).

Signed-off-by: Oliver Brown <b37094@b37094-vmlinux.(none)>
---
 drivers/mxc/ipu3/ipu_regs.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)  mode change 100644 => 100755
drivers/mxc/ipu3/ipu_regs.h

--
1.7.9.5
Otavio Salvador - Sept. 16, 2013, 9:19 p.m.
On Mon, Sep 16, 2013 at 5:34 PM, Dennis Han <jshan@live.co.kr> wrote:
> I tested you patch more detail and found a problem.
>
> In brief.
>
> 1. With original value
> IC_RSZ_MAX_RESIZE_RATIO = 0x00004000
>>> it's OK
>
>
> 2. With a new value
> IC_RSZ_MAX_RESIZE_RATIO = 0x00002000
>>> center pixels are overlapping
>
>
> I think this patch has to be ignored.

Good for testing and letting us know about the result. Eric, does it
also fails for you?
Eric Nelson - Sept. 17, 2013, 12:23 a.m.
On 09/16/2013 02:19 PM, Otavio Salvador wrote:
> On Mon, Sep 16, 2013 at 5:34 PM, Dennis Han <jshan@live.co.kr> wrote:
>> I tested you patch more detail and found a problem.
>>
>> In brief.
>>
>> 1. With original value
>> IC_RSZ_MAX_RESIZE_RATIO = 0x00004000
>>>> it's OK
>>
>>
>> 2. With a new value
>> IC_RSZ_MAX_RESIZE_RATIO = 0x00002000
>>>> center pixels are overlapping
>>
>>
>> I think this patch has to be ignored.
>
> Good for testing and letting us know about the result. Eric, does it
> also fails for you?
>

The re-sizing patch did nothing for me, while our patch
fixed the issue playing the file in both qtmediaplayer
and gst-launch/playbin2.

I'm not testing with qt-in-use-image, but another qt4e
image with a patched-up 4.0.0 kernel.

This makes sense because the video is 1280x720 and the
display is also 1280x720.

Dennis, is this your screen resolution?

Please advise,


Eric
Eric Nelson - Sept. 17, 2013, 12:37 a.m.
On 09/16/2013 05:23 PM, Eric Nelson wrote:
> On 09/16/2013 02:19 PM, Otavio Salvador wrote:
>> On Mon, Sep 16, 2013 at 5:34 PM, Dennis Han <jshan@live.co.kr> wrote:
>>> I tested you patch more detail and found a problem.
>>>
>>> In brief.
>>>
>>> 1. With original value
>>> IC_RSZ_MAX_RESIZE_RATIO = 0x00004000
>>>>> it's OK
>>>
>>>
>>> 2. With a new value
>>> IC_RSZ_MAX_RESIZE_RATIO = 0x00002000
>>>>> center pixels are overlapping
>>>
>>>
>>> I think this patch has to be ignored.
>>
>> Good for testing and letting us know about the result. Eric, does it
>> also fails for you?
>>
>
> The re-sizing patch did nothing for me, while our patch
> fixed the issue playing the file in both qtmediaplayer
> and gst-launch/playbin2.
>
> I'm not testing with qt-in-use-image, but another qt4e
> image with a patched-up 4.0.0 kernel.
>
> This makes sense because the video is 1280x720 and the
> display is also 1280x720.
>

I meant to add some details about what we're seeing.

It's very clear when playing full-screen that the
issue is one of a missing color-space conversion.

Playing Dennis' video clearly shows that the data
is in NV12 (YUV planar) format, with two instances
of the video across the top of the screen, followed
by a very distorted bottom 1/3 or so.

Our patch circumvents code elsewhere in the V4L2
driver that appears to be an optimization for the
case where the YUV plane can be output directly and
the display can somehow do the conversion.

	https://github.com/boundarydevices/linux-imx6/commit/c4eb189e1cae98c5535c0a26e859a010b0c70510

Also interesting is that when qmediaplayer starts up,
it seems to tell V4L2 to start up a 1280x720 plane,
but not at offset 0,0. In other words, it's not full-screen,
so the "bypass CSC" logic seems to be missing another
component in determining whether the YUV plane is "full screen".

Oh, and the Qt4 Phonon layer should probably be patched
to shrink the overlay size if the initial window position
doesn't allow the overlay to fit on the screen.

Regards,


Eric
Otavio Salvador - Sept. 17, 2013, 1:47 a.m.
On Mon, Sep 16, 2013 at 9:37 PM, Eric Nelson
<eric.nelson@boundarydevices.com> wrote:
> On 09/16/2013 05:23 PM, Eric Nelson wrote:
>>
>> On 09/16/2013 02:19 PM, Otavio Salvador wrote:
>>>
>>> On Mon, Sep 16, 2013 at 5:34 PM, Dennis Han <jshan@live.co.kr> wrote:
>>>>
>>>> I tested you patch more detail and found a problem.
>>>>
>>>> In brief.
>>>>
>>>> 1. With original value
>>>> IC_RSZ_MAX_RESIZE_RATIO = 0x00004000
>>>>>>
>>>>>> it's OK
>>>>
>>>>
>>>>
>>>> 2. With a new value
>>>> IC_RSZ_MAX_RESIZE_RATIO = 0x00002000
>>>>>>
>>>>>> center pixels are overlapping
>>>>
>>>>
>>>>
>>>> I think this patch has to be ignored.
>>>
>>>
>>> Good for testing and letting us know about the result. Eric, does it
>>> also fails for you?
>>>
>>
>> The re-sizing patch did nothing for me, while our patch
>> fixed the issue playing the file in both qtmediaplayer
>> and gst-launch/playbin2.
>>
>> I'm not testing with qt-in-use-image, but another qt4e
>> image with a patched-up 4.0.0 kernel.
>>
>> This makes sense because the video is 1280x720 and the
>> display is also 1280x720.
>>
>
> I meant to add some details about what we're seeing.
>
> It's very clear when playing full-screen that the
> issue is one of a missing color-space conversion.
>
> Playing Dennis' video clearly shows that the data
> is in NV12 (YUV planar) format, with two instances
> of the video across the top of the screen, followed
> by a very distorted bottom 1/3 or so.
>
> Our patch circumvents code elsewhere in the V4L2
> driver that appears to be an optimization for the
> case where the YUV plane can be output directly and
> the display can somehow do the conversion.
>
>
> https://github.com/boundarydevices/linux-imx6/commit/c4eb189e1cae98c5535c0a26e859a010b0c70510

Shouldn't 'g_fb_setting[i].disp_support_csc' be fixed to properly return 0?

> Also interesting is that when qmediaplayer starts up,
> it seems to tell V4L2 to start up a 1280x720 plane,
> but not at offset 0,0. In other words, it's not full-screen,
> so the "bypass CSC" logic seems to be missing another
> component in determining whether the YUV plane is "full screen".
>
> Oh, and the Qt4 Phonon layer should probably be patched
> to shrink the overlay size if the initial window position
> doesn't allow the overlay to fit on the screen.

Patches?! This is 'encrypted' for me so I have no way to help on this ;-)
Dennis Han - Sept. 17, 2013, 5:17 a.m.
Hi Eric.

It makes sense. And your patch work well too.
I'll take your patch.


-----Original Message-----
From: Eric Nelson [mailto:eric.nelson@boundarydevices.com] 
Sent: Tuesday, September 17, 2013 9:37 AM
To: Otavio Salvador; Sandoval Gonzalez Leonardo-B42214
Cc: Dennis Han; meta-freescale@yoctoproject.org
Subject: Re: [meta-freescale] gstreamer strange distorted image.

On 09/16/2013 05:23 PM, Eric Nelson wrote:
> On 09/16/2013 02:19 PM, Otavio Salvador wrote:
>> On Mon, Sep 16, 2013 at 5:34 PM, Dennis Han <jshan@live.co.kr> wrote:
>>> I tested you patch more detail and found a problem.
>>>
>>> In brief.
>>>
>>> 1. With original value
>>> IC_RSZ_MAX_RESIZE_RATIO = 0x00004000
>>>>> it's OK
>>>
>>>
>>> 2. With a new value
>>> IC_RSZ_MAX_RESIZE_RATIO = 0x00002000
>>>>> center pixels are overlapping
>>>
>>>
>>> I think this patch has to be ignored.
>>
>> Good for testing and letting us know about the result. Eric, does it 
>> also fails for you?
>>
>
> The re-sizing patch did nothing for me, while our patch fixed the 
> issue playing the file in both qtmediaplayer and gst-launch/playbin2.
>
> I'm not testing with qt-in-use-image, but another qt4e image with a 
> patched-up 4.0.0 kernel.
>
> This makes sense because the video is 1280x720 and the display is also 
> 1280x720.
>

I meant to add some details about what we're seeing.

It's very clear when playing full-screen that the issue is one of a missing color-space conversion.

Playing Dennis' video clearly shows that the data is in NV12 (YUV planar) format, with two instances of the video across the top of the screen, followed by a very distorted bottom 1/3 or so.

Our patch circumvents code elsewhere in the V4L2 driver that appears to be an optimization for the case where the YUV plane can be output directly and the display can somehow do the conversion.

	https://github.com/boundarydevices/linux-imx6/commit/c4eb189e1cae98c5535c0a26e859a010b0c70510

Also interesting is that when qmediaplayer starts up, it seems to tell V4L2 to start up a 1280x720 plane, but not at offset 0,0. In other words, it's not full-screen, so the "bypass CSC" logic seems to be missing another component in determining whether the YUV plane is "full screen".

Oh, and the Qt4 Phonon layer should probably be patched to shrink the overlay size if the initial window position doesn't allow the overlay to fit on the screen.

Regards,


Eric
Eric Nelson - Sept. 17, 2013, 1:31 p.m.
On 09/16/2013 06:47 PM, Otavio Salvador wrote:
> On Mon, Sep 16, 2013 at 9:37 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>> On 09/16/2013 05:23 PM, Eric Nelson wrote:
>>>
>>> On 09/16/2013 02:19 PM, Otavio Salvador wrote:
>>>>
>>>> On Mon, Sep 16, 2013 at 5:34 PM, Dennis Han <jshan@live.co.kr> wrote:
>>>>
>> Our patch circumvents code elsewhere in the V4L2
>> driver that appears to be an optimization for the
>> case where the YUV plane can be output directly and
>> the display can somehow do the conversion.
>>
>> https://github.com/boundarydevices/linux-imx6/commit/c4eb189e1cae98c5535c0a26e859a010b0c70510
>
> Shouldn't 'g_fb_setting[i].disp_support_csc' be fixed to properly return 0?
>

It seems that I got tired or hungry when walking this backward
from the decision to skip color-space conversion ;)

Thanks for pointing this out.

Patch

diff --git a/drivers/mxc/ipu3/ipu_regs.h b/drivers/mxc/ipu3/ipu_regs.h old
mode 100644 new mode 100755 index 94c587e..f089f7d
--- a/drivers/mxc/ipu3/ipu_regs.h
+++ b/drivers/mxc/ipu3/ipu_regs.h
@@ -465,7 +465,7 @@  enum {
 	IC_CONF_RWS_EN = 0x40000000,
 	IC_CONF_CSI_MEM_WR_EN = 0x80000000,
 
-	IC_RSZ_MAX_RESIZE_RATIO = 0x00004000,
+	IC_RSZ_MAX_RESIZE_RATIO = 0x00002000,
 
 	IC_IDMAC_1_CB0_BURST_16 = 0x00000001,
 	IC_IDMAC_1_CB1_BURST_16 = 0x00000002,