linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Wood <d01.devel@gmail.com>
To: mchehab@kernel.org
Cc: linux-media@vger.kernel.org
Subject: [PATCH] media: em28xx: complete frames from non-interlaced sources
Date: Fri, 18 Sep 2026 18:07:42 -0400	[thread overview]
Message-ID: <20260918220743.2043647-1-d01.devel@gmail.com> (raw)

Non-interlaced 60 Hz sources, such as the 240p output of classic game
consoles, produce 262 lines per field with no half-line offset, so every
field has the same parity. The TVP5150 tracks such a signal without
trouble (locked, 60 Hz, vertical line count 524 instead of 525) but
reports the same field ID for every field, and the em2860 forwards that
in its field-start header. On an EM2860/TVP5150 reference design
(eb1a:5051) fed by a NES, 112 of 113 consecutive headers in a 6 s stream
carry field ID 1 (bottom); the lone top-field header is the first one.

finish_field_prepare_next() only completes a buffer and starts the next
one when a top field arrives, so with such a source no frame is ever
delivered: streaming starts, the first buffer never finishes, and the
application sits in select() until it times out. Disturbing the cable
briefly loses sync, yields a stray top-field header and lets a single
frame through -- the "one frame, then it freezes" symptom.

Track the previous field ID. When a header repeats the ID of the field
before it, give the new field the opposite parity instead of taking the
ID literally, so consecutive fields are woven into a frame the same way
a genuine top/bottom pair is. Interlaced streams alternate IDs and are
unaffected. A dropped field in one now lands two bottom fields in the
same buffer, which the copy path already tolerates, and the following
top field starts a new frame as before.

With this the NES streams at 29.9 fps with a stable, correctly woven
picture. Each frame holds two consecutive progressive source frames, so
an application that wants the source's 60 fps back can bob-deinterlace.

Signed-off-by: David Wood <d01.devel@gmail.com>
---
 drivers/media/usb/em28xx/em28xx-video.c | 26 +++++++++++++++++++++++--
 drivers/media/usb/em28xx/em28xx.h       |  1 +
 2 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-video.c b/drivers/media/usb/em28xx/em28xx-video.c
index 5f13f63..5b570a9 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -627,6 +627,27 @@ finish_field_prepare_next(struct em28xx *dev,
 	return buf;
 }
 
+/*
+ * Set the parity of the field that starts with this header.
+ *
+ * Non-interlaced sources, such as the 240p output of classic game consoles,
+ * generate every field with the same parity, so the bridge reports the same
+ * field ID over and over. A top field never arrives and no frame is ever
+ * completed. Detect a repeated field ID and alternate the parity instead, so
+ * consecutive fields are woven into a frame like a genuine interlaced pair.
+ */
+static inline void em28xx_set_field_parity(struct em28xx_v4l2 *v4l2,
+					   int field_id)
+{
+	bool top_field = !(field_id & 1);
+
+	if (field_id == v4l2->last_field_id)
+		top_field = !v4l2->top_field;
+
+	v4l2->last_field_id = field_id;
+	v4l2->top_field = top_field;
+}
+
 /*
  * Process data packet according to the em2710/em2750/em28xx frame data format
  */
@@ -661,14 +682,14 @@ static inline void process_frame_data_em28xx(struct em28xx *dev,
 			v4l2->capture_type = 0;
 			v4l2->vbi_read = 0;
 			em28xx_isocdbg("VBI START HEADER !!!\n");
-			v4l2->top_field = !(data_pkt[2] & 1);
+			em28xx_set_field_parity(v4l2, data_pkt[2] & 1);
 			data_pkt += 4;
 			data_len -= 4;
 		} else if (data_pkt[0] == 0x22 && data_pkt[1] == 0x5a) {
 			/* Field start (VBI disabled) */
 			v4l2->capture_type = 2;
 			em28xx_isocdbg("VIDEO START HEADER !!!\n");
-			v4l2->top_field = !(data_pkt[2] & 1);
+			em28xx_set_field_parity(v4l2, data_pkt[2] & 1);
 			data_pkt += 4;
 			data_len -= 4;
 		}
@@ -1099,6 +1120,7 @@ int em28xx_start_analog_streaming(struct vb2_queue *vq, unsigned int count)
 		em28xx_wake_i2c(dev);
 
 		v4l2->capture_type = -1;
+		v4l2->last_field_id = -1;
 		rc = em28xx_init_usb_xfer(dev, EM28XX_ANALOG_MODE,
 					  dev->analog_xfer_bulk,
 					  EM28XX_NUM_BUFS,
diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h
index f3449c2..dc732f6 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -588,6 +588,7 @@ struct em28xx_v4l2 {
 	/* Capture state tracking */
 	int capture_type;
 	bool top_field;
+	int last_field_id;
 	int vbi_read;
 	unsigned int field_count;
 

                 reply	other threads:[~2026-09-18 22:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260918220743.2043647-1-d01.devel@gmail.com \
    --to=d01.devel@gmail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).