Re: [PATCHv2 7/7] [PATCHv5] media: adv7180: fix field type

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

 




On 08/03/2016 04:42 PM, Ian Arkver wrote:
> On 03/08/16 15:23, Lars-Peter Clausen wrote:
>> On 08/03/2016 04:11 PM, Hans Verkuil wrote:
>>>
>>> On 08/03/2016 03:21 PM, Niklas Söderlund wrote:
>>>> On 2016-08-02 17:00:07 +0200, Lars-Peter Clausen wrote:
>>>>> [...]
>>>>>> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
>>>>>> index a8b434b..c6fed71 100644
>>>>>> --- a/drivers/media/i2c/adv7180.c
>>>>>> +++ b/drivers/media/i2c/adv7180.c
>>>>>> @@ -680,10 +680,13 @@ static int adv7180_set_pad_format(struct v4l2_subdev *sd,
>>>>>>   	switch (format->format.field) {
>>>>>>   	case V4L2_FIELD_NONE:
>>>>>>   		if (!(state->chip_info->flags & ADV7180_FLAG_I2P))
>>>>>> -			format->format.field = V4L2_FIELD_INTERLACED;
>>>>>> +			format->format.field = V4L2_FIELD_ALTERNATE;
>>>>>>   		break;
>>>>>>   	default:
>>>>>> -		format->format.field = V4L2_FIELD_INTERLACED;
>>>>>> +		if (state->chip_info->flags & ADV7180_FLAG_I2P)
>>>>>> +			format->format.field = V4L2_FIELD_INTERLACED;
>>>>> I'm not convinced this is correct. As far as I understand it when the I2P
>>>>> feature is enabled the core outputs full progressive frames at the full
>>>>> framerate. If it is bypassed it outputs half-frames. So we have the option
>>>>> of either V4L2_FIELD_NONE or V4L2_FIELD_ALTERNATE, but never interlaced. I
>>>>> think this branch should setup the field format to be ALTERNATE regardless
>>>>> of whether the I2P feature is available.
>>> Actually, that's not true. If the progressive frame is obtained by combining
>>> two fields, then it should return FIELD_INTERLACED. This is how most SDTV
>>> receivers operate.
>> This is definitely not covered by the current definition of INTERLACED. It
>> says that the temporal order of the odd and even lines is the same for each
>> frame. Whereas for a deinterlaced frame the temporal order changes from
>> frame to frame.
>>
>> E.g. lets say you have half frames A, B, C, D, E, F ...
>>
>> The output of the I2P core are frames like (A,B) (C,B) (C,D) (E,D) (E, F) ...
>>
>> The first frame is INTERLACED_TB, the second INTERLACED_BT, the third
>> INTERLACED_TB again and so on. Also you get the same amount of pixels as for
>> a progressive setup so the data-output-rate is higher. Maybe we need a
>> FIELD_DEINTERLACED to denote such a setup?
> I don't think this is correct. The ADV7280 has no framestore, just a 
> small linebuffer. It does I2P by line doubling plus some filtering and a 
> little bit of proprietary magic, allegedly.
> 
> I believe the output in I2P mode for your example would be (AA) (BB) 
> (CC). The clock rate and pixel rate is doubled since it sends a full 
> (faked up) frame per field time.
> 
> I don't know what the FIELD_* mode is for line doubled pseudo-progressive.

We don't have one for that either. You really shouldn't do tricks like that,
it's rather pointless and gives horrible quality.

> 
> Also, I don't know why anyone would use this mode. I don't see a 
> scenario where it would actually improve video quality over a more 
> sophisticated motion adaptive deinterlace and to restore a 25/30fps feed 
> you'd need to decimate and lose information.

Indeed.

> 
> Quote from "Rob.Analog", who uses the word "frame" freely, here: 
> https://ez.analog.com/thread/39382
> 
> "2) In I2P mode the number of lines per frame doubles. The ADV7280 still 
> outputs 50 frames per second ( or 60 frames in NTSC mode) but each frame 
> now consists of twice as many lines. e.g. if a frame consisted of 288 
> lines of active video in interlaced mode, this is doubled to 576 lines 
> of active video in progressive mode. The line doubling is achieved by 
> the ADV7280 interpolating between two lines of video (e.g. between lines 
> 1 and 3 on an odd frame) and inserting an extra line (e.g. line 2). 
> There are also some ADI propriety algorithms that prevent low angle 
> noise artifacts.
> 
> In order to achieve this line doubling, the LLC clock doubles from a 
> nominal 27MHz to a nominal 54MHz"

It looks like you are correct. I wouldn't bother implementing this.

Regards,

	Hans



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux