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.
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.
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"
Regards,
IanJ
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
