Re: downscaling YUV fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2012-12-19 15:00, Archit Taneja wrote:
> On Wednesday 19 December 2012 06:07 PM, Tomi Valkeinen wrote:
>> On 2012-12-19 14:19, Archit Taneja wrote:
>>
>>>> The image I get is stable, and clearly something that happens when,
>>>> say,
>>>> row_inc is one pixel too much, or similar.
>>>
>>> Ok, about the width in this case. The original width is 400, and what we
>>> finally want is 220. After pre-decimation, the width would become 200,
>>> and we would need our scalar to actually upscale to 220.
>>>
>>> I am wondering if the driver gets confused when such a scenario occurs,
>>> or the DSS HW is weird when we upscale some predecimated content. If you
>>> look at the hinc(1024  * width/out_width) value in the FIR register, in
>>> the "ok" regdumps, the value is 1861, which points to downscaling. And
>>> in the fail case, it's 92, which is upscaling.
>>
>> I can reproduce this with a very simple case. 400x200 -> 200x200, and
>> forcing horizontal predecimation. So this will cause no scaling to be
>> used, only the pixel_inc is used to downscale.
> 
> Ah okay. My guess was wrong then :)
> 
>>
>> The VID1 registers are as follows. They look right to me...
>>
>> DISPC_OVL_BA0(VID1)                                8d900000
>> DISPC_OVL_BA1(VID1)                                8d900000
>> DISPC_OVL_POSITION(VID1)                           00000000
>> DISPC_OVL_SIZE(VID1)                               00c700c7
>> DISPC_OVL_ATTRIBUTES(VID1)                         00608011
>> DISPC_OVL_FIFO_THRESHOLD(VID1)                     03ff03c0
>> DISPC_OVL_FIFO_SIZE_STATUS(VID1)                   00000400
>> DISPC_OVL_ROW_INC(VID1)                            00000001
>> DISPC_OVL_PIXEL_INC(VID1)                          00000005
>> DISPC_OVL_PRELOAD(VID1)                            00000100
>> DISPC_OVL_FIR(VID1)                                04000400
>> DISPC_OVL_PICTURE_SIZE(VID1)                       00c700c7
>> DISPC_OVL_ACCU0(VID1)                              00000000
>> DISPC_OVL_ACCU1(VID1)                              00000000
>> DISPC_OVL_PRELOAD(VID1)                            00000100
> 
> The only thing which seems not so nice is that vertical taps and vid
> line buffer split are enabled in OVL_ATTRIBUTES. These shouldn't be
> harmful though.

Yep, I've tested disabling five_taps also, but it doesn't have any effect.

I'm at loss here =). If I force pix inc to 1, I get what I expect: an
image without skew, but the height is doubled as the left and right
sides are shows on two lines. Then setting pix inc to 5 causes the skew.
Colors are still correct, so the byte alignment is right.

 Tomi


Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux