On 08/03/2016 04:23 PM, 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) ...
Yuck.
What most devices do is (A,B) (C,D) (E,F) ...
That's FIELD_INTERLACED.
>
> 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?
>
Yeah, this is a completely different mode. Do we even want to support this?
Does anyone need this mode? I think we should leave it out until someone actually
wants to use it. And then we need to come up with a new FIELD_ mode.
Regards,
Hans
